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Federation  Development  and  Execution 
Process  (FEDEP)  Tools  in  Support  of  NATO 
Modelling  &  Simulation  (M&S)  Programmes 

(RTO-TR-MSG-005) 

Executive  Summary 

MSG-005,  PathFinder  FEDEP  Support  Tools,  was  initiated  following  a  NATO  Industry  Advisory  Group 
(NIAG)  Working  Group  report  titled,  “Follow-on  NIAG  Prefeasibility  Studies  on  Common  Technical 
Framework  and  Multi-National  Force  Rehearsal  (PathFinder  Experiment  Definition)”.  This  report 
recommended  the  establishment  of  a  new  Working  Group  to  define  Initial  Common  Tools  (ICTs)  required 
to  support  Multi-National  PathFinder  Federations.  The  following  nations  contributed  to  the  work  of 
MSG-005:  Canada,  France,  Germany,  Portugal,  United  States,  and  United  Kingdom. 

NMSG  Task  Group  005  held  its  first  meeting  in  February  2001.  The  original  plan  was  to  complete  the  task 
in  two  years  to  ensure  that  the  report  would  provide  timely  information  to  the  PathFinder  group.  As  the 
PathFinder  schedule  slipped,  however,  MSG  005  took  advantage  of  the  additional  time  to  expand  its 
scope. 

The  Task  Group  recognized  the  value  of  the  NIAG  study  and  recommended  the  development  of  a  product 
that  would  be  broadly  supportive  of  the  development  of  High  Level  Architecture  (HLA)  based  federations 
across  NATO.  The  mission  of  MSG-005,  in  accordance  with  the  TOR  was  “the  identification  of  the 
availability  of  the  most  appropriate  and  cost-effective  FEDEP  support  tools  [. . .]  to: 

•  Reduce  cost  of  simulation  development; 

•  Improve  training  simulations; 

•  Promote  reuse  of  national  models  and  simulations  in  a  multi-national  federation.” 

More  specifically,  MSG  005  was  to: 

•  Identify  the  most  appropriate  and  cost-effective  PathFinder  FEDEP  support  tools,  e.g.,  scenario 
preparation,  environmental  data,  requirement  definition,  configuration  management; 

•  Determine  the  availability  of  the  most  appropriate  and  cost-effective  PathFinder  FEDEP  support 
tools,  whether  commercial,  academic,  government,  or  military  products; 

•  Recommend  the  development  of  new  FEDEP  support  tools. 

Liaison  was  established  with  the  European  Co-operation  for  Long-term  in  Defence  Research  and 
Technology  Programme,  EUCLID  RTP  11.13  (“Realizing  the  potential  of  Synthetic  Environments  in 
Europe”).  This  effort  combined  with  the  NIAG  report  and  the  original  DMSO  HLA  Tools  Database 
formed  a  basis  for  the  MSG  005  study. 

Task  Group  members  considered  2  competing  approaches  for  the  development  of  the  final  product. 
The  first  was  to  recommend  a  tool  set  to  support  the  PathFinder  Development  and  Execution  Process, 
and  the  second  was  to  create  a  searchable  collection  of  descriptions  of  available  tools.  The  latter  approach 
was  selected  since  it  met  the  requirements  of  the  PathFinder  Programme,  and  served  the  needs  of  broader 
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NATO  modelling  and  simulation  community.  The  tool  list  itself  is  indexed  to  the  new  IEEE  1516.3™  - 
2003  standard:  “IEEE  Recommended  Practice  for  High  Level  Architecture  (HLA)  Federation 
Development  and  Execution  Process  (FEDEP)”.  In  an  effort  to  ease  maintenance  in  the  future,  this  tool  list 
focuses  exclusively  on  modelling  and  simulation  tools,  omitting  general  software  development  and 
support  products.  The  list  currently  contains  79  tools  and  others  should  be  added  as  they  become  known. 

Finally,  the  Task  Group  has  recommended  that  the  tool  list  be  made  available  through  a  web-based 
interface,  to  ease  access  and  use.  In  support  of  this  concept,  a  formal  recommendation  was  made  at  the 
8th  NATO  M&S  Business  Meeting  in  The  Hague  (in  2001)  to  establish  a  common  set  of  web-based  M&S 
repository  services  to  support  all  of  NATO. 

This  report  details  the  work  of  the  Task  Group  and  includes  the  methodology  and  rationale  for  the 
development  of  the  tool  list.  Chapter  1  is  the  Introduction  which  discusses  the  origin  of  the  MSG-005 
activity  and  scope  of  the  report.  Chapter  2  provides  background  information  on  the  FEDEP  and  the 
FEDEP  Tools  Overlay.  Chapter  3  discusses  the  PathFinder  program  and  related  work  and  Chapter  4 
addresses  the  tools,  the  report  methodology  and  an  explanation  of  the  technical  approach  and  analysis. 
Conclusions  and  recommendations  are  contained  in  Chapter  5. 


IV 


RTO-TR-MSG-005 


NATO 

OTAN 

ORGAI4^IZATION 


Des  outils  d’aide  au  processus  de  developpement 
et  d’ execution  de  federations  (FEDEP) 
(RTO-TR-MSG-005) 


Synthese 

Le  groupe  MSG-005  sur  les  outils  de  soutien  pour  le  FEDEP  Pathfinder  a  ete  cree  suite  a  la  publication  du 
rapport  du  groupe  consultatif  industriel  OTAN  (NIAG)  intitule  «  Etudes  de  pre-faisabilite 
complementaires  NIAG  sur  1’ infrastructure  technique  commune  de  simulation  et  I’entrainement  des  forces 
multinationales  (definition  de  1’ experimentation  Pathfinder)  ».  Ce  rapport  a  recommande  la  creation  d’un 
nouveau  groupe  de  travail,  ayant  pour  mandat  de  definir  les  outils  communs  de  base  (ICT)  demandes  pour 
le  soutien  de  federations  multinationales  Pathfinder.  Les  pays  suivants  ont  contribue  aux  travaux  du  MSG- 
005  :  Le  Canada,  la  France,  I’Allemagne,  le  Portugal,  les  Etats-Unis,  et  le  Royaume-Uni. 

Le  groupe  de  travail  NMSG  005  a  tenu  sa  premiere  reunion  en  fevrier  2001.  Son  objectif  initial  etait  de 
terminer  ses  travaux  dans  un  delai  de  deux  ans,  afin  de  pouvoir  foumir  un  rapport  en  temps  voulu  au 
groupe  Pathfinder.  Cependant,  puisque  le  planning  Pathfinder  avait  glisse,  le  groupe  a  profile  du  temps 
additionnel  pour  developper  ses  activites. 

Le  groupe  de  travail  a  reconnu  I’interet  de  I’etude  NIAG  et  a  recommande  le  developpement  d’un  produit 
plus  general  pour  soutenir  le  developpement  de  federations  basees  sur  F  architecture  de  haul  niveau  (HE A) 
au  sein  de  I’OTAN.  Conformement  a  son  TOR,  le  groupe  MSG-005  a  eu  pour  mandat  «  F identification  de 
la  disponibilite  des  outils  de  soutien  les  plus  appropries  et  les  plus  rentables  [. . .]  afin  de  : 

•  reduire  le  cout  de  developpement  des  simulations  ; 

•  ameliorer  les  simulations  d’entrainement ; 

•  promouvoir  la  re-utilisation  de  modeles  nationaux  au  sein  d’une  federation  multinationale.  » 

En  particulier,  MSG-005  devait : 

•  identifier  les  outils  de  soutien  au  FEDEP  de  Pathfinder  les  plus  appropries  et  les  plus  rentables, 
par  exemple,  la  preparation  des  scenarios,  les  donnees  d’environnement,  la  definition  des  besoins, 
la  gestion  de  la  configuration  etc.  ; 

•  determiner  la  disponibilite  des  outils  de  soutien  au  FEDEP  de  Pathfinder  les  plus  appropries  et  les 
plus  rentables,  qu’il  s’agisse  de  produits  commerciaux,  universitaires,  gouvemementaux  ou 
militaries  ; 

•  formuler  des  recommandations  concemant  le  developpement  de  nouveaux  outils  de  soutien  au 
FEDEP. 

Un  lien  a  etc  etabli  avec  le  Programme  Europeen  de  Cooperation  en  Recherche  et  Technologic  pour  la 
Defense  a  Long  Terme,  EUCLID  RTP  11.13  («  Realiser  le  potentiel  des  SE  en  Europe  »).  Ces  travaux, 
le  rapport  du  NIAG  et  la  base  de  donnees  d’outils  HLA  du  DMSO,  ont  constitue  les  bases  de  Fetude 
MSG  005. 

Les  membres  du  groupe  de  travail  ont  examine  deux  approches  concurrentes  pour  le  developpement  du 
produit  final,  a  savoir,  la  recommandation  d’un  jeu  d’outils  pour  le  soutien  du  processus  de 
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developpement  et  d’ execution  de  Pathfinder  d’une  part,  et  la  creation  d’une  base  de  donnees  decrivant  les 
outils  disponibles  d’ autre  part.  La  deuxieme  approche  a  ete  retenue  puisqu’elle  correspondait  aux  criteres 
du  programme  Pathfinder  et  qu’elle  repondait  aux  attentes  des  specialistes  OTAN  de  la  modelisation  et  de 
la  simulation.  La  liste  des  outils  est  indexee  a  la  nouvelle  norme  IEEE  1516.3™  :  «  La  pratique 
recommandee  IEEE  pour  1’ architecture  de  haut  niveau  (HLA)  processus  de  developpement  et  d’execution 
de  federations  (FEDEP)  ».  Dans  un  souci  de  faciliter  la  maintenance  future,  cette  liste  est  composee 
exclusivement  d’ outils  specifiques  a  la  modelisation  et  la  simulation,  a  1’ exclusion  de  tout  produit  general 
de  developpement  et  de  soutien  logiciel.  Aujourd’hui,  la  liste  contient  79  outils  et  d’autres  y  seront  ajoutes 
au  fur  et  a  mesure  de  leur  apparition. 

Enfin,  le  groupe  de  travail  a  recommande  la  mise  a  disposition  de  la  liste  d’outils  par  I’intermediaire  d’une 
interface  Web,  afin  de  la  rendre  accessible  et  exploitable  par  le  plus  grand  nombre  de  personnes. 
Pour  promouvoir  ce  concept,  une  recommandation  officielle  a  ete  faite  lors  de  la  Seme  reunion  NATO 
M&S  a  la  Haye  (en  2001)  relative  a  la  creation  d’une  bibliotheque  M&S  sur  le  Web  pour  le  soutien  de 
I’ensemble  des  pays  membres  de  I’OTAN. 

Ce  rapport  donne  la  description  detaillee  des  travaux  du  groupe  de  travail,  y  compris  la  methodologie  et 
les  objectifs  adoptes  lors  de  I’elaboration  de  la  liste  d’outils.  En  guise  d’ introduction,  le  chapitre  1 
examine  les  origines  de  I’activite  MSG-005,  ainsi  que  le  champs  d’activites  convert  par  le  rapport. 
Le  chapitre  2  presente  I’historique  du  FEDEP  et  des  outils.  Le  chapitre  3  examine  le  programme 
Pathfinder  et  le  travaux  associes.  Le  chapitre  4  porte  sur  les  outils,  la  methodologie  adoptee  pour  le 
rapport  et  commente  I’approche  technique  et  I’analyse.  Le  chapitre  5  contient  des  conclusions  et  des 
recommandations . 
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Chapter  1  -  INTRODUCTION 


1.1  ORIGIN  OF  THE  TECHNICAL  ACTIVITY  PROGRAMME 

In  1996,  a  temporary  North  Atlantic  Treaty  Organization  (NATO)  working  group  was  convened  to  assess 
the  possibility  of  establishing  a  permanent  Modelling  and  Simulation  (M&S)  organisation.  This  working 
group,  the  Steering  Group  for  M&S  (SGMS),  reported  to  both  the  Conference  of  National  Armament 
Directors  (CNAD)  and  the  Military  Committee  (MC)  via  the  Research  and  Technology  Organisation 
(RTO). 

In  1998,  the  SGMS  published  two  documents: 

•  A  final  report  proposing  a  NATO  M&S  organisation 

•  A  NATO  M&S  Master  Plan  (MSMP)  [A.2-1] 

Both  documents  were  approved  by  the  RTO,  CNAD  and  MC  hierarchy,  and  ultimately  by  the  North 
Atlantic  Council  (NAC)  in  November  1998.  Since  then,  the  NATO  M&S  Organisation  has  been 
established  under  the  auspices  of  the  RTO  as  shown  in  Figure  1.  The  NATO  M&S  Organisation  is 
composed  of  the  NATO  M&S  Group  (NMSG)  and  the  M&S  Coordination  Office  (MSCO).  The  NMSG  is 
a  leading  committee  that  meets  twice  a  year.  It  is  supported  by  the  MSCO,  which  has  a  permanent  office 
that  is  installed  in  the  Research  and  Technology  Agency  (RTA)  in  Neuilly-sur-Seine,  France. 


Figure  1:  NATO  Modelling  and  Simulation  Organisation. 

The  NATO  MSMP,  referenced  above,  addressed  a  variety  of  M&S  subjects.  Its  five  objectives  are  shown 
below  in  Table  1.  Notable  among  these  was  the  subject  of  modelling  and  simulation  standards  under 
Objective  1.  Both  the  approved  MSMP  and  the  SGMS  final  reports  recognised  the  High  Level 
Architecture  (HLA)  [A.3-1  to  A.3-9]  as  the  primary  NATO  M&S  interoperability  standard.  Since  that 
time,  the  HLA  has  matured  and  is  now  being  recommended  by  the  NMSG  as  a  NATO  Standard 
(STANAG). 


1  -1 


RTO-TR-MSG-005 


INTRODUCTION 


Table  1:  MSMP  Objectives 


Objective  1 

Objective  2 

Objective  3 

Objective  4 

Objective  5 

Establish  a 
Common 
Technical 
Framework 

Provide 
Common 
Services  in 
NATO  M&S 

Develop 

Simulations 

Employ 

Simulations 

Incorporate 

Technological 

Advances 

1.1  Adopt  HLA 

2.1  Compile 
M&S  Information 

3.1  Identify  & 
Prioritise 
Requirements 

4.1  Plan 
Employment 

5.1  Monitor 
M&S  Related 
Advances 

1.2  Establish 
Data 

Interchange 

Standards 

2.2  Provide 
M&S  Education 

3.2  Identify 
Strategies 

4.2  Provide 
Resources 

5.2  Conduct 
R&D 

2.3  Establish  a 
Simulation 
Resource 
Library 

3.3  Allocate 
Resources 

4.3  Provide 
Databases 

5.3  Share 
Information 

2.4  Establish  a 
Help  Desk 

3.4  Execute 
Strategy 

4.4  Operate 
Simulations 

5.4  Implement 
Advances 

3.5  Provide 
Feedback 

4.5  Conduct 
Impact 
Assessment 

Objective  3  of  the  MSMP  led  to  the  PathFinder  initiative.  It  states:  “the  development  of  individual  models 
and  simulations  has  been  occurring  for  decades  and  is  relatively  well  understood.  However,  NATO  has 
limited  experience  with  the  co-operative  development  of  federations  of  diverse  simulations.”  To  address 
this  issue,  the  MSMP  discussed  the  need  for  a  PathFinder  programme  to  demonstrate  the  viability  of 
co-operatively  developed  multi-national  distributed  federations  based  on  the  HLA. 

The  origin  of  the  MSG-005  technical  activity  came  from  Objective  1,  “Establish  a  Common  Technical 
Framework”,  or  more  specifically.  Sub-objective  1.1,  which  recommended  the  adoption  of  the  HLA  as  the 
interoperability  standard  within  NATO.  The  PathFinder  programme  was  initiated  to  support  this  objective 
and  specifically  to  provide  a  mechanism  for  HLA  experimentation.  A  number  of  Technical  Activity 
Programmes  (TAPs)  have  been  created  within  the  NMSG  to  support  PathFinder;  MSG-005  is  one  of  them. 

In  the  year  2000,  prior  to  the  formation  of  MSG-005,  a  NATO  Industry  Advisory  Group  (NIAG)  Working 
Group  completed  its  study  [A.2-2,  A.2-3].  One  of  the  products  of  the  study  was  the  identification  of  the 
support  tools  required  for  PathFinder.  This  study  formed  the  foundation  for  the  MSG-005  Task  Group. 
More  specifically,  the  MSG-005  Terms  Of  Reference  (TOR)  [A.  1-1]  state  the  mission  of  the  Task  Group 
as: 


The  identification  of  the  availability  of  the  most  appropriate  and  cost-effective  FEDEP  [Federation 
Development  and  Execution  Process]  support  tools  [which]  will  allow  NMSG  to  recommend  that 
NATO  defines  a  set  of  standard  common  tools  to  support  employment  of  an  integrated  high-level 
simulated  mission  space  that  can  support  NATO  in  the  principal  application  areas  of  defence 
planning,  training,  exercises  and  support  to  operations  to: 

•  Reduce  [the]  cost  for  simulation  development 

•  Improve  training  simulations 

•  Promote  re-use  of  national  models  and  simulations  in  a  multi-national  federation 


1  -2 


RTO-TR-MSG-005 


INTRODUCTION 


As  stated  in  the  TOR,  the  main  tasks  of  MSG-005  are  to: 

a)  Identify  the  most  appropriate  and  cost-effective  PathFinder  FEDEP  support  tools,  e.g.,  scenario 
preparation,  environmental  data,  requirement  definition,  configuration  management 

b)  Identify  the  availability  of  [the]  most  appropriate  and  cost-effective  PathFinder  FEDEP  support 
tools,  whether  commercial,  academic,  government,  or  military  products 

c)  Recommend  the  development  of  new  FEDEP  support  tools 


1.2  RELATED  WORKING  GROUPS 

Task  Group  MSG-005  was  established  to  support  the  NATO  PathFinder  programme,  which  is  described  in 
some  detail  in  Section  3.1  of  this  document.  The  current  programme  organisation  is  composed  of  a 
PathFinder  Steering  Group  (PSG),  which  consists  of  senior  leaders  from  the  NMSG.  The  PSG  meets  four 
times  a  year  and  formed  MSG-002,  another  NMSG  Task  Group.  MSG-002  was  in  charge  of  specifying  the 
future  development  of  PathFinder  according  to  a  tailored  version  of  the  FEDEP  (described  in  Chapter  2). 
This  version  is  referred  to  as  the  PathFinder  Development  and  Execution  Process  (PADEP).  France  was 
leading  the  nine  nations  that  participated  in  MSG-002,  which  completed  its  work  in  June  2003. 

Upon  the  completion  of  MSG-002,  Germany  started  to  lead  a  new  PathFinder  Task  Group  designated 
MSG-027.  The  title  of  this  group  is:  “PathFinder:  Integration  Environment  for  Multi-Purpose  Application 
of  Distributed  Networked  Simulations”. 

MSG-012  was  another  Task  Group  that  had  a  strong  link  with  MSG-005.  Its  focus  was  the  establishment 
of  a  NATO  Simulation  Resources  Library  (SRL).  MSG-005  believes  that  the  tool  database  that  it  is 
developing  should  be  made  available  and  maintained  on  this  resource.  For  this  reason,  MSG-012  and 
MSG-005  established  close  co-ordination. 

Though  not  explicitly  mentioned  in  their  titles,  there  are  other  RTO  Task  Groups  that  will  benefit  from  the 
output  of  MSG-005.  MSG-00 l/SAS-034,  “Distributed  Mission  Rehearsal  for  NATO  Combined  Air 
Operations”,  which  is  preparing  a  demonstration  based  on  an  HLA  federation,  is  a  good  example.  In  fact, 
more  than  half  of  the  MSG  Task  Groups  have  expressed  an  interest  in  MSG-005  activities. 

Outside  the  NMSG  community,  other  programmes  also  maintain  a  strong  interest  in  MSG-005.  The  main 
interest  exists  under  the  auspices  of  the  European  Co-operation  for  the  Long  Term  In  Defence  (EUCLID) 
consortium.  This  effort  is  led  by  the  Common  European  Priority  Area  (CEP A)  1 1  steering  committee  on 
M&S,  within  a  Task  Group  identified  as  Research  and  Technology  Project  (RTP)  11.13,  “Realising  the 
Potential  of  Synthetic  Environments  in  Europe”.  Chapter  3  of  this  document  provides  more  detailed 
information  on  this  parallel  work.  Some  MSG-005  Task  Group  members  are  involved  in  RTP  11.13  and 
are  ensuring  that  close  co-ordination  is  maintained  between  the  two  groups. 


1.3  PARTICIPATING  NATIONS 

The  nations  and  one  organisation  participating  in  MSG-005  are: 

•  Canada 

•  France 

•  Germany 

•  Portugal 

•  United  Kingdom  (UK) 
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•  United  States  (US)  (chair) 

•  NATO  MSCO 

Note:  Poland  expressed  an  interest  in  participating  but  was  unable  to  send  a  representative  to  the  meetings. 


1.4  SCOPE  OF  THE  REPORT 

The  main  deliverables  of  the  MSG-005  Task  Group  are: 

•  this  report,  and 

•  a  list  of  tools  and  related  information  in  extensible  Mark-up  Language  (XML)  format. 

The  scope  of  the  report  is  as  follows: 

•  Chapter  2  describes  the  history  of  the  HLA  Federation  Development  and  Execution  Process  and 
the  development  of  software  tools  to  support  it. 

•  Chapter  3  gives  an  overview  of  the  PathFinder  programme  and  previous  work  related  to  the 
selection  of  software  tools  for  this  programme  and  EUCLID  RTP  11.13. 

•  Chapter  4  presents  the  methodology  that  was  used  to  develop  the  list  of  tools,  an  overview  of  the 
database  schema,  and  an  analysis  of  the  tools  in  the  database. 

•  Chapter  5  completes  the  report  with  conclusions  and  recommendations. 

Due  to  the  volume  of  information,  this  report  does  not  list  all  of  the  information  in  the  database;  however. 
Annex  E  describes  the  database  structure  and  Annex  F  lists  all  of  the  tools  with  some  key  information  that 
was  extracted  from  the  database. 
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2.1  FEDEP  HISTORY 

When  the  initial  definition  of  the  HLA  was  first  made  public  in  March  1995,  a  number  of  new  concepts 
were  introduced.  One  of  these  was  the  notion  of  a  “federation”,  which  was  defined  as  a  set  of  “federates” 
(software  applications)  capable  of  exchanging  information  based  on  an  agreed  upon  interchange  document 
known  as  a  Federation  Object  Model  (FOM).  The  data  is  exchanged  through  a  communication  layer 
known  as  the  Run-Time  Infrastructure  (RTI).  For  more  detailed  information  concerning  the  HLA, 
see  References  A.3-1  to  A. 3 -9. 

During  1995-1996,  a  number  of  participating  organisations  were  identified  to  build  prototype  HLA 
federations.  Although  the  three  components  of  the  HLA  provided  the  required  “pieces”  for  building 
a  federation,  there  was  no  process  guidance  by  which  federations  could  be  developed.  In  fact, 
each  application  developer  was  forced  to  define  their  own  practices  and  procedures  for  HLA  federation 
development  and  execution.  This  resulted  in  a  large  amount  of  trial-and-error  experimentation  and  high 
levels  of  consumed  resources.  In  addition,  the  prototype  federations  reported  that  the  lack  of  process 
guidance  would  likely  be  a  persistent  barrier  to  HLA  acceptance  and  cross-domain  interoperability  and 
collaboration. 

Throughout  the  HLA  prototyping  period,  there  were  a  wide  variety  of  approaches  to  HLA  federation 
development.  These  approaches  and  development  concepts  were  shared  among  the  different  domains  via 
the  HLA  Object  Model  Template  (OMT)  Working  Group.  These  discussions  led  to  several  instances  of 
group  consensus  on  “best  practices”  for  various  aspects  of  federation  development.  During  the  final 
briefings  of  the  HLA  prototype  federations,  a  unanimous  recommendation  was  reached  to  establish  a 
common  process  view  for  HLA  federation  development  and  execution. 

Initially,  the  HLA  OMT  Working  Group  provided  the  forum  for  sharing  federation  development  practices 
and  approaches,  and  in  September  1996,  the  first  release  of  the  HLA  Federation  Development  and 
Execution  Process  (FEDEP)  took  place.  Version  1.0  of  the  FEDEP  was  based  on  experiences  within  the 
prototype  federations  and  incorporated  the  best  practices,  as  they  were  understood  at  that  time. 

In  November  1997,  a  Concept  of  Operations  (ConOps)  was  established  to  mature  and  evolve  the  FEDEP 
in  a  structured  fashion.  The  Simulation  Interoperability  Standards  Organization  (SISO)  Simulation 
Interoperability  Workshops  (SIWs)  were  a  key  element  of  this  strategy.  The  Federation  Development 
Process  (PROC)  Forum  was  established  by  SISO  to  provide  an  open  forum  for  exchanging  ideas, 
concepts,  and  practical  experiences  regarding  the  process  of  federation  development.  In  the  Call  For 
Papers  (CFP)  for  each  subsequent  SIW,  the  PROC  Forum  sought  out  papers  that  contributed  to  this 
charter.  As  these  papers  were  presented,  suggestions  for  FEDEP  modifications  and  enhancements  were 
discussed  and  documented.  The  HLA  Architecture  Management  Group  (AMG)  later  reviewed  those 
suggestions.  The  approved  changes  were  implemented  in  a  new  FEDEP  release  and  the  process  was 
repeated  for  later  versions.  This  first  cycle  of  changes  implemented  minor  changes  to  the  FEDEP  diagram 
and  resulted  in  FEDEP  Version  1.1. 

In  July  1998,  the  review  cycle  included  improvements  to  the  process  description  regarding  roles 
and  products.  It  also  addressed  the  topic  of  federation  re-use  and  resulted  in  FEDEP  Version  1.2. 
The  December  1998  review  cycle  improved  the  graphical  representation  and  Version  1.3  was  released. 

FEDEP  Version  1.4,  released  during  June  of  1999,  incorporated  an  executive  summary  and  partitioned 
federation  design  and  development  into  two  steps.  The  final  version  of  the  first  FEDEP  generation. 
Version  1.5  [A.3-1],  was  created  in  December  1999  and  contained  only  minor  editorial  changes. 
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With  this  release,  the  FEDEP  had  undergone  five  full  cycles  of  the  ConOps.  In  releases  1.1  to  1.4, 
feedback  on  the  FEDEP  document  was  heavy  and  resulted  in  a  number  of  significant  improvements. 
However,  FEDEP  Version  1.5  (Figure  2)  implemented  only  minor  editorial  changes  with  no  new  changes 
proposed  for  the  sixth  development  cycle;  a  planned  Version  1.6  release  was  deferred  as  a  result. 
The  PROC  Forum  believed  that  this  decrease  in  change  requests  provided  direct  evidence  that  the  process 
model  description  had  stabilized.  Additional  information  on  the  development  of  the  FEDEP  can  be  found 
on  the  PROC  Forum  area  of  the  SISO  archives  at  http://www.sisostds.org/. 
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Figure  2:  Six-Step  FEDEP  Version  1.5  (December  1999). 


2.2  THE  CURRENT  FEDEP  VERSION 

With  the  Institute  of  Electrical  and  Electronic  Engineers  (IEEE)  society  approval  of  the  HLA  1516  series 
of  specifications,  the  PROC  Forum  recommended  to  the  SISO  Standards  Activity  Committee  (SAC)  that  a 
supporting  process  model  was  still  needed  by  the  HLA  user  community  for  requirements  development, 
conceptual  modelling,  scenario  development,  federation  development  and  execution.  These  activities  were 
considered  critical  to  the  successful  development  of  an  HLA  federation  but  were  clearly  outside  of  the 
scope  of  the  HLA  specifications. 

Including  the  FEDEP  as  part  of  the  IEEE  1516  series  of  documents  would  help  to  fulfil  the  need  for  a 
process  model.  The  M&S  community  also  believed  that  the  FEDEP  would  improve  and  mature  with  the 
wider  community  involvement  brought  on  by  the  IEEE  standardisation  process,  as  did  the  HLA. 

Today,  the  current  version  of  the  FEDEP  (Figure  3)  embodies  many  of  the  comments  and  contributions 
from  NATO  and  the  broader  European  communities.  The  NATO  PathFinder  programme  and  EUCLID 
RTP  1 1.13,  as  well  as  significant  individual  contributions,  have  broadened  and  matured  the  FEDEP  to  the 
point  that  it  was  accepted  as  an  IEEE  standard  in  March  2003  [A. 3 -9]. 
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Figure  3:  Seven-Step  FEDEP  (3  June  2002). 


2.3  TOOLS  TO  SUPPORT  THE  FEDEP 

During  the  early  development  of  the  HLA,  it  became  apparent  that  a  set  of  tools  was  required  to  support 
early  technology  adopters.  The  challenges  were  how  to  determine  which  tools  to  build  in  order  to  provide 
the  greatest  benefit,  and  how  to  ensure  that  commercial  vendors  would  have  an  opportunity  to  compete  in 
this  endeavour.  The  answer  lay,  in  part,  in  the  development  of  the  HLA  Tools  Architecture  (Figure  4). 

The  architecture  was  created  as  an  overlay  to  the  FEDEP  in  an  effort  to  show  the  relationship  of  the  tools 
to  the  FEDEP.  This  approach  demonstrated  the  notional  types  of  tools  that  were  available  to  support  each 
phase  of  development  and  their  relationship  to  the  process  and  tools  in  the  later  phases.  The  architecture 
not  only  depicts  the  tools  and  supporting  repositories  but  also  the  flow  of  data  from  one  phase  of  the 
FEDEP,  and  corresponding  set  of  tools,  to  another  using  a  set  of  standardised  Data  Interchange  Formats 
(DIFs). 

The  architecture  itself  is  divided  from  left  to  right  by  the  phases  of  the  FEDEP. 

The  tools  shown  in  the  architecture  are  of  two  major  types.  The  boxes  represent  end-user  tools  and  the 
cylinders  depict  library  resources  that  can  be  shared  by  all  HLA  users. 
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Figure  4:  HLA  Tools  Architecture:  Mapping  Tools  on  the  FEDEP. 

On  the  left-hand  side  of  the  chart,  the  architecture  is  divided  horizontally  into  three  categories: 

•  General-purpose  tools  not  specific  to  the  M&S  domain 

•  M&S-specific  tools 

•  HLA-specific  tools  and  repositories 

The  HLA  developed  tools  can  further  be  divided  into  three  groups: 

•  Object  model  tools 

•  Federation  development  tools 

•  Federation  run-time  tools 

As  previously  discussed,  the  tools  are  connected  within  the  architecture  by  a  set  of  standardised  Data 
Interchange  Formats.  These  DIFs  provide  a  specification  of  the  semantics  and  structure  of  data  to  be 
interchanged  between  multiple  data-producers  and  multiple  data-consumers.  Also  note  that  the  DIFs  were 
produced  in  co-operation  with  commercial  tool  vendors.  This  ensured  that  their  tools  were  interchangeable 
with  those  being  developed  by  the  US  Department  of  Defense  (DoD)  Defense  Modeling  and  Simulation 
Office  (DMSO). 

The  HLA  DIFs  support  the  interchange  of  tools  within  the  architecture  without  any  resulting  loss  of  data. 
For  example.  Object  Modelling  Development  Tools  (OMDTs)  from  multiple  vendors  may  be  used  by  the 
various  members  of  an  HLA  federation.  The  tools  can  all  be  initialised  by  extracting  Simulation  Object 
Models  (SOMs)  or  Federation  Object  Models  (FOMs)  from  the  Object  Model  Resource  Repository. 
Each  of  the  different  OMDTs  will  output  data  in  standardized  formats  that  can  also  be  used  by  other  tools 
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later  in  the  federation  development  cycle.  This  approach  allows  users  to  choose  among  the  available  tools 
knowing  that  they  are  interchangeable  with  the  DMSO-sponsored  tools. 

The  DIFs  also  ensure  that  data  produced  during  one  phase  of  federation  development  can  be  automatically 
transferred  to  another  and  used  by  a  tool  in  that  phase.  Again,  using  the  OMDT  as  an  example,  the  output 
of  the  OMDT  from  any  vendor  can  be  used  to  automatically  populate  the  Federation  Execution  Planners’ 
Workbook  (FEPW)  files,  eliminating  the  need  to  recreate  the  information  in  the  FEPW. 

In  short,  the  tool  architecture  identifies  the  types  of  tools  that  are  required  and  used  during  federation 
development  and  execution.  It  ensures  that  as  long  as  a  tool  uses  the  standardised  DIFs,  the  tool  will  be 
interchangeable  with  others  of  the  same  kind,  and  that  the  data  produced  can  be  used  in  subsequent  phases 
of  federation  development  and  execution. 
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3.1  PATHFINDER 

3.1.1  Background 

In  the  past,  NATO  has  relied  on  the  principle  that  training  by  individual  nations  should  meet  the  readiness 
requirements  of  the  Alliance.  Today,  however,  NATO  faces  new  challenges  in  Europe.  One  challenge  is 
the  new  NATO  structure  with  new  nations  becoming  incorporated  into  the  Alliance.  Another  is  the 
increasing  number  of  Crisis  Response  Operations  (CROs)  involving  the  deployment  of  multi-national 
forces  engaged  in  new  and  complex  scenarios. 

The  difficulties  of  this  new  situation  have  prompted  the  development  of  an  overarching  NATO  Training, 
Exercise,  and  Evaluation  Policy  (Military  Committee  document  MC  458).  Parallel  developments,  such  as 
the  Partnership  for  Peace  (PfP)  Training  and  Education  Enhancement  Programme  (TEEP),  MC  94/4 
NATO  Military  Exercise  Policy,  ACE  (Allied  Command  Europe)  Command  and  Staff  Training 
Programme  (ACSTP),  and  Joint  Analysis  Lessons  Learned  Centre  (JALLC),  have  already  demanded  an 
increasing  training  involvement  by  NATO. 

The  ability  to  practice  NATO  staff  procedures  under  realistic  conditions  and  in  a  cost-effective  manner 
requires  a  technological  leap  ahead.  Specifically,  it  requires  the  employment  of  Computer  Assisted 
Exercises  (CAXs)  that  are  seamlessly  connected  to  the  NATO  Communication  Information  System  (CIS). 

One  of  the  objectives  of  the  PathFinder  programme  is  to  address  these  issues  by  providing  a  training 
capability  supported  by  modelling  and  simulation.  PathFinder  deals  with  the  integration  and  employment 
of  multi-national  models  and  Decision  Support  Tools  (DSTs)  for  the  Combined-Joint  Task  Force  (CJTF) 
Headquarters  (HQ)  and  lower  component  commands. 

PathFinder  is  a  follow-on  programme  of  the  Distributed  Multi-National  Defence  Simulation  (DiMuNDS) 
2000  feasibility  demonstration.  The  DiMuNDS  project  was  a  highly  successful  pre-PathFinder 
experimental  federation.  It  established  the  technical  viability  of  combining  multi-national  simulations 
using  the  HLA  for  the  purpose  of  providing  training  and  exercise  support  in  a  CJTF  operational  context. 
This  programme  culminated  with  a  demonstration  of  its  technical  capabilities  at  the  NATO  M&S 
Conference  in  October  2000.  The  PathFinder  programme,  building  on  this  success,  will  provide  a 
technological  leap  ahead  for  NATO  and  PfP  nations.  Eight  nations,  as  well  as  the  main  NATO 
organisations,  now  actively  support  PathFinder. 

3.1.2  Description 

The  vision  of  the  PathFinder  programme  is  to  provide  the  technical  capability  for  federations  of  national 
models  and  DSTs  to  be  integrated  and  linked  to  NATO  and  National  Command,  Control,  Communications 
and  Intelligence  (C3I)  systems.  These  federations  will  be  linked  for  the  purposes  of  exercising  and  training 
the  CJTF  HQ  staff  and  component  commands  in  the  conduct  of  Crisis  Response  Operations. 

The  PathFinder  programme  is  now  assessing  a  number  of  promising  national  models  with  Non-Article  5 
CRO  capabilities  for  possible  integration.  The  identification  and  selection  of  the  best  and  most  appropriate 
models  is  part  of  the  initial  phase  of  the  programme.  For  several  years,  NATO  agencies  and  NATO 
Technical  Activity  Programmes  have  been  studying  and  developing  the  concept  of  the  CAX.  They  have 
been  using  national  models  linked  via  tailored  software  architectures.  While  the  work  has  been  very 
extensive,  the  success  and  utility  of  these  programmes  has  not  been  leveraged  outside  of  the  individual 
working  groups.  PathFinder  offers  a  solution  to  this  problem  (Figure  5). 
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Figure  5:  Pathfinder  Vision  Integrated  into  the  Future  NATO  CAX  Capability. 


Other  important  by-products  of  this  multi-national  linkage  of  national  simulations  will  be  the 
interoperability  of  national  simulations  and  CISs,  and  the  standardisation  of  tools  and  services.  Additional 
by-products  will  be  the  creation  of  common  databases  and  the  development  of  secure  communication 
networks. 

The  use  of  federations  composed  of  different  national  models  may  also  offer  enhanced  detail,  fidelity  and 
realism  (capabilities  sought  by  Operational  Commands)  over  that  of  the  monolithic  simulations  that  are 
employed  today.  Federations  are  capable  of  providing  greater  fidelity  in  each  of  the  Air,  Land  and 
Maritime  domains,  and  they  also  offer  the  possibility  of  dynamically  linking  families  of  models  with 
different  levels  of  resolution.  This  more  flexible,  multi-resolution  approach  enhances  the  training  value  of 
the  models  and  the  ability  to  validate  and  improve  NATO  doctrine. 

3.1.3  Type  of  Capability 

PathFinder  is  not  a  dedicated  HLA  federation.  It  is  a  programme  to  acquire  and  enhance  the  capability 
to  assemble  simulation  environments  consisting  of  distributed  national  or  NATO  agency  simulations, 
DSTs  and  NATO  CISs,  to  form  flexible  federations  adapted  to  meet  specific  requirements.  In  so  doing, 
PathFinder  will  converge  with  future  NATO  CAX  capabilities  to  help  deal  with  the  development  of  CAXs 
and  DSTs. 

3.1.4  Concept 

The  PathFinder  capability  will  not  only  support  training  but  also  the  capability  to  provide  operational 
support  to  NATO  commanders.  PathFinder  implies  the  use  of  three  functional  networks: 
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•  Operational  CIS:  This  is  the  operational  CIS  that  NATO  commanders  employ  in  the  conduct  of 
any  NATO  operation.  The  operational  commander  interfaces  with  this  network,  receiving 
information  on  operational  progress  and  inputting  commands  and  actions  to  influence  the  course 
of  the  operation. 

•  Exercise  Control  Network:  This  is  the  network  through  which  the  Exercise  Control  element 
communicates  with  the  response  cells.  It  is  outside  of  the  exercise  command  and  control  system. 

•  Simulation  Wide  Area  Network  (WAN)/Local  Area  Network  (LAN):  This  network  is  the 
backbone  of  the  CAX.  It  is  used  to  exchange  data  between  simulation  federates.  Additionally, 
response  cells  provided  by  nations  or  NATO  communicate  with  component  response  cells  and 
common-resource  management  personnel  using  this  network. 

The  PathFinder  concept  relies  on  the  HLA  standards  and  the  national  skills  and  experience  now  prevalent 
in  the  field  of  distributed  simulation.  Building  a  high-fidelity  flexible  simulation  composed  of  dissimilar 
simulations  is  possible  today  using  this  architecture.  The  “federation  of  models”  approach  is  believed  to 
facilitate  the  transparency,  flexibility  and  validation  of  the  simulation  environment.  In  the  near  future, 
war-gaming  federations  will  be  an  important  part  of  CIS,  operations  planning,  and  doctrine  development. 
The  opportunity  to  train  at  different  levels  is  provided  with  the  development  of  appropriate  federations. 
Additionally,  the  employment  of  nationally  federated  models  in  operational  support  roles  will  facilitate  the 
development  of  doctrine  and  tactics. 

In  order  for  all  of  this  to  work,  a  commonality  of  data  standards  and  consistency  of  independent  databases 
will  also  be  required.  Working  towards  this  goal  is  important  to  the  overall  outcome  of  the  PathFinder 
programme. 

3.1.5  Summary 

The  vision  of  the  PathFinder  programme  is  to  provide  HLA  federations  consisting  of  national  models  and 
DSTs  that  can  be  linked  to  operational  C3I  systems  to  exercise  and  train  the  CJTF  HQ  and  Component 
Commanders.  The  PathFinder  programme  will  also  provide  dynamic  support  and  will  represent  a  major 
technological  leap  forward  for  the  CJTF  HQ  training  in  the  conduct  of  Crisis  Response  Operations. 

Typically,  nations  have  observed  a  significant  increase  in  training  and  exercise  effectiveness  and  a  ten-fold 
reduction  in  cost  when  employing  CAX  compared  to  conducting  live  exercises  at  the  CJTF  HQ  level. 

Important  by-products  of  this  multi-national  linkage  of  national  simulations  will  be: 

•  The  interoperability  of  national  simulations 

•  The  standardisation  of  tools  and  services 

•  The  creation  of  consistent  databases 

•  The  improvement  of  the  international  community  of  simulation  developers 

The  feasibility  phase  of  PathFinder  is  currently  underway.  It  is  being  funded  by  national  contributions. 


3.2  SYNOPSIS  OF  RELATED  WORK 
3.2.1  NIAG  Report 

Chapter  7  of  the  NIAG  report  [A.2-3]  identifies  “Initial  Common  Tools”  (ICTs)  for  use  by  countries 
participating  in  the  PathFinder  programme.  The  tools  consist  of  applications  such  as  Commercial  Off-The- 
Shelf  (COTS)  products,  required  services  such  as  “email”  and  “security”,  and  some  data-type 
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specifications  such  as  Digital  Terrain  Elevation  Data  (DEED).  Very  few  COTS  products  are  listed  and 
specific  tools  for  services  such  as  “Network  Devices”  are  not  listed  at  all. 

To  assess  the  ICTs,  30  criteria  are  listed  in  Table  7.1  of  Reference  A.2-3  under  the  following  seven 
categories  (the  bracketed  numbers  indicate  the  number  of  criteria  in  each): 

•  Availability  (3) 

•  Usefulness  (2) 

•  Platform  Support  (3) 

•  Credibility  and  Reliability  (3) 

•  Usability  (7) 

•  Documentation  (7) 

•  Capability  to  Evolve  (5) 

Since  the  assessments  of  individual  ICTs  are  not  presented  in  the  NIAG  report,  it  is  difficult  to  assess  the 
effort  that  went  into  the  evaluations. 

Table  7.2  in  Reference  A.2-3  lists  32  ICTs  under  7  tool  requirement  categories.  The  table  indicates 
whether  the  ICT  is  HLA  specific,  which  step  of  the  PADEP  (PathFinder  Development  and  Execution 
Process)  requires  it,  and  if  it  currently  exists  as  a  commercial,  government,  or  military  tool  (as  opposed  to 
one  that  needs  to  be  developed).  The  categories  and  the  number  of  ICTs  in  each  are: 

•  F ederation  Development  Tools  (13) 

•  Scenario  Generation  Tools  (3) 

•  Federation  Control  and  Feedback  Tools  (5) 

•  After  Action  Review  (AAR)  Tools  (2) 

•  Federation  Support  Tools  (4) 

•  Response  Cells  Support  Tools  (2) 

•  Data  Sets  (3) 

Each  of  the  categories  is  further  broken  down  and  the  requirements,  existing  tools,  importance,  and 
recommendations  for  each  are  briefly  discussed.  The  report  makes  numerous  recommendations  to  evaluate 
the  ICTs.  Some  are  very  specific  (“Use  the  Object  Model  Library  (OML)”)  while  others  are  very  general 
(“Define  a  unique,  widely  spread  tool  for  all  team  members”). 

Few  COTS  or  Government-Off-The-Shelf  (GOTS)  tools  are  listed  in  the  various  categories  and  individual 
evaluations  are  not  presented.  Thus,  a  more  extensive  review  is  required,  as  well  as  explicit  analyses  of  the 
tool  capabilities.  This  report  addresses  these  issues. 

Another  key  issue  addressed  in  the  NIAG  report  is  interoperability.  Unfortunately,  this  issue  is  not  a 
property  of  any  one  tool  and  cannot  be  addressed  at  this  time.  Once  candidate  tools  are  selected,  their 
ability  to  interoperate  must  be  studied  in  detail.  Interoperation  should,  in  the  simplest  case,  support  the 
same  file  formats  and  versions,  complement  each  other,  and,  for  the  sake  of  cost  effectiveness,  have 
minimum  overlapping  capabilities.  Several  commercial  products  listed  in  the  MSG-005  tool  list  embody 
these  features  in  tool  suites. 
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3.2.2  EUCLID  RTF  11.13 

The  EUCLID  RTF  11.13  programme  “Realising  the  Potential  of  Synthetic  Environments  in  Europe”  is  a 
multi-national  effort  under  the  authority  of  the  Western  Europe  Armament  Group  (WE AG).  The  objective 
of  EUCLID  RTP  11.13  is  to  mitigate  the  obstacles  that  prevent  networked  simulations  from  being 
exploited  in  Europe,  by  developing  a  process  for  the  production,  execution  and  evaluation  of  networked 
simulations,  including  an  integrated  set  of  prototype  software  tools  to  support  the  process.  The  aim  is  to 
reduce  the  cost  and  timescales  associated  with  developing  networked  simulation  environments  for 
collective  training,  mission  rehearsal  and  simulation-based  acquisition  applications.  Key  to  this  aim  is  the 
development  of  software  required  to  set  up  a  European  repository  of  simulation  assets. 

The  EUCLID  RTP  11.13  programme  is  jointly  funded  by  23  commercial  organisations  and  13  member- 
nations  of  the  WEAG.  The  programme  is  overseen  by  representatives  of  the  national  ministries  of  defence 
of  those  countries  involved,  in  the  form  of  a  Management  Group  (MG)  led  by  the  UK.  EUCLID  RTP 
11.13  is  a  three-year  effort  initiated  in  November  2000  and  scheduled  to  end  in  October  2003. 
The  programme  has  a  budget  in  excess  of  17-million  Euros. 

Among  the  many  Work  Elements  (WEs)  of  RTP  11.13,  WE  1.2,  “Review  of  Application  Tools”,  has  an 
objective  similar  to  that  of  MSG-005.  Its  aim  is  “to  identify  and  evaluate  the  applicability  of  tools  that  will 
support  the  generation  and  utilisation  of  SEs  [synthetic  environments]”.  The  focus  of  the  work  is  to  ensure 
that  managers  are  aware  of  what  SE  tools  are  already  available  so  that  time  and  money  is  not  wasted 
duplicating  their  functionality  in  new  software. 

Since  the  focus  of  RTP  1 1.13  is  not  the  same  as  that  of  PathFinder,  WE  1.2  spent  a  limited  amount  of  time 
on  the  analysis  of  existing  tools.  Therefore,  only  a  top-level  review  was  performed  to  identify  the  part(s) 
of  the  networked  simulation  lifecycle  that  a  tool  supports. 

The  types  and  numbers  of  tools  reviewed  were: 

•  Scenario  generation  tools  (7) 

•  HLA  support  tools  (22) 

•  AAR  tools  (such  as  data  loggers)  (3) 

•  Requirements  analysis  tools  (3) 

•  Requirements  management  tools  (1) 

•  Computer-generated  forces  (2) 

•  Execution  support  tools  (network  analysis,  voice,  and  two-dimensional  (2D)  or  three-dimensional 
(3D)  visualisation  tools)  (10) 

Information  about  the  tools  was  collected  using  a  questionnaire  that  was  sent  out  to  the  nations 
participating  in  the  EUCLID  programme.  The  results  were  entered  into  a  Microsoft®  Access©  database, 
which  can  be  accessed,  searched  and  sorted  via  a  web  browser. 

The  EUCLID  RTP  11.13  Management  Group  has  agreed  that  the  deliverables  of  WE  1.2  can  be  shared 
with  NATO  MSG-005.  Thus,  the  WE  1.2  database  was  selected  as  one  source  of  information  for  the  Task 
Group. 
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4.1  ASSUMPTIONS 

The  catalogue  of  tools  established  by  the  MSG-005  Task  Group  provides  information  that  is  necessary  for 
users  and  developers  of  HLA  federations,  but  it  is  by  no  means  exhaustive. 

MSG-005  considered  including  general-purpose  applications  and  software  development  tools  in  the 
database  but  eventually  decided  to  exclude  them.  The  Task  Group  felt  that  the  software  development 
community  is  generally  aware  of  such  tools  and  would  not  be  inclined  to  look  for  information  on  them  in 
the  MSG-005  database.  In  addition,  listing  all  such  tools  would  have  expanded  the  list  to  an  unmanageable 
size  and  made  future  database  maintenance  much  more  difficult. 

Some  tool  characteristics  were  also  excluded  from  the  database  in  order  to  minimise  the  difficulty  and 
recurring  cost  of  database  maintenance.  Typically,  product  information  that  varies  with  the  size  and  scope 
of  the  project,  such  as  product  cost,  was  omitted.  Contact  information  was  included  so  that  fluctuating 
product  information  can  be  easily  determined. 

Schedule  and  budget  constraints  for  PathFinder  and  MSG-005  precluded  addressing  all  of  the  tool 
requirements  that  were  identified  in  the  NIAG  report.  For  example,  new  tools  must  be  developed  to  satisfy 
some  of  the  requirements  but  creating  new  applications  was  beyond  the  scope  of  the  MSG-005  TAP. 


4.2  METHODOLOGY 

The  results  presented  in  this  report  are  based  on  lessons  learned  and  previous  tool  surveys  that  support  the 
set-up  and  execution  of  HLA  federations.  More  specifically,  two  sources  of  information  have  been  used  as 
the  basis  for  this  study  (Figure  6): 

•  The  HLA  Bulletin  Board 

•  The  tool  list  developed  by  the  EUCLID  RTP  11.13  consortium^ 


DMSO‘s  HLA 
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MSG-005 

Research 
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Information  about 
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w/  potential 
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Figure  6:  Schematic  Sketch  of  the  Expioited  Methodoiogy. 


^  See  http://www.euelidl  1 1 3.eom/deliverables/reports/WEl .2/default.htm. 
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MSG-005  considered  two  competing  ways  of  using  this  information.  The  first  was  to  create  a  searchable 
collection  of  available  tools.  Such  a  catalogue  would  contain  a  brief  tool  description  along  with 
information  on  its  availability  and  potential  use.  The  catalogue  would  only  provide  information  on  tools 
that  were  expected  to  be  of  interest  to  federation  developers;  it  would  not  give  recommendations  for  or 
against  a  specific  tool. 

The  second  option  was  to  recommend  a  set  of  tools  to  support  the  PADEP.^  Similar  to  the  efforts  of 
EUCLID  RTP  11.13,  such  a  tool  set  would  directly  support  the  PathFinder  programme  and  cover  all  steps 
of  the  FEDEP/PADEP.  It  would  consist  of  a  selection  of  currently  available  tools  or  new  tools  built 
especially  for  PathFinder. 

Although  the  heading  of  this  TAP  suggests  the  second  option  would  be  chosen,  MSG-005  decided  to 
pursue  the  first  for  the  following  reasons: 

•  The  requirements  definition  phase  of  PathFinder  is  being  developed  independently  of  this  TAP 
and  has  not  been  finalised  for  use  by  MSG-005.  Therefore,  identifying  tools  against  evolving 
requirements  was  considered  too  risky. 

•  A  dedicated  tool  set  suited  for  PathFinder  would  have  been  inflexible.  The  first  option,  however, 
was  open  to  any  federated  simulation  environment  and  would  serve  a  broader  section  of  the  M&S 
community. 

•  The  development  of  a  tool  set  is  a  major  undertaking  as  the  experiences  from  EUCLID  RTP  11.13 
demonstrated.  When  MSG-005  started,  PathFinder  had  an  ambitious  timeline  and  the 
development  of  a  specific  tool  set  could  have  delayed  the  programme. 

To  summarize,  the  MSG-005  Task  Group  decided  to  concentrate  on  tools  specific  to  the  development  of 
any  HLA  federation,  not  just  PathFinder.  Nevertheless,  two  co-ordination  meetings  occurred  with  the 
PathFinder  programme  to  ensure  their  requirements  were  being  met. 

General-purpose  software  development  tools  were  excluded  because  of  the  assumptions  discussed  above. 
The  database  does  not  contain  product  marketing  or  commercial  details  because  the  Task  Group  had  no 
desire  to  provide  extensive  commercial  information  or  to  promote  specific  tools.  Instead,  Point  of  Contact 
(POC)  information  has  been  provided  for  those  desiring  additional  information. 


4.3  TOOL  LIST  DATABASE 

The  database  was  to  be  based  on  the  DMSO  and  EUCLID  tool  lists  enriched  by  the  investigations  and 
contributions  of  the  MSG-005  Task  Group  members.  However,  upon  initial  investigation  of  the  DMSO 
and  EUCLID  tool  lists,  the  MSG-005  Task  Group  discovered  that  the  level  of  detail  was  inadequate  for  its 
purposes.  Therefore,  a  spreadsheet  was  created  to  store  more  detailed  information. 

At  first,  use  of  Microsoft®  Excel©  or  Access©  for  storing  and  retrieving  tool  information  looked  quite 
promising.  Unfortunately,  refining  the  data  structures  became  complex.  Eventually,  XML  was  chosen  to 
develop  the  database  because  it  offered  a  more  flexible  and  effective  solution.  Figure  7  shows  the  XML 
editor  used  to  develop  the  tool  list  database. 


^  See  Seetion  1.2  and  Chapter  3. 
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^  XML  Spy  -  [M5G005 ToolListi@i2002-010-08.xml] 
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Figure  7:  Screen-Shot  of  the  Tool  List  within  the  Database  Development  Software. 


Additionally,  XML  made  the  use  of  Hyper  Text  Mark-up  Language  (HTML)  possible  for  output  pages, 
making  a  web-like  interface  feasible.  The  ease  of  using  an  Internet  browser  to  search  the  database 
solidified  the  decision.  That  said,  other  output  formats,  such  as  Adobe®  Portable  Document  Format  (PDF), 
can  still  be  produced  without  affecting  the  data  set. 

A  spiral  development  process  was  used  to  produce  the  database.  After  a  draft  definition  of  the  logical 
structure.  Task  Group  members  were  assigned  responsibility  for  tools  and  provided  a  list  of  background 
information  corresponding  to  the  database  elements.  The  logical  structure,  in  terms  of  a  Document  Type 
Definition  (DTD)  or  schema,  is  explained  further  in  Section  4.4  and  Annex  E.  From  this,  an  XML  extract 
was  generated  and  entered  into  the  data  file.  The  logical  structure  and  tool  information  were  revised  three 
times  prior  to  finalisation  of  the  data  set. 


4.4  THE  XML  SCHEMA 

The  basic  philosophy  behind  XML  is  the  separation  of  structure,  content  and  presentation  style.  An  XML 
project  like  the  FEDEP  tool  list  consists  of  three  parts: 

•  The  XML  Schema  Definition:  In  this  file  (extension  “.xsd”),  the  logical  structure  of  the  data  is 
contained  in  XML  syntax.  Alternatively,  a  Document  Type  Definition  (DTD)  file  (extension 
“.dtd”)  can  be  used,  which  contains  the  equivalent  information  in  Backus-Naur  Form. 

•  The  XML  file:  This  file  contains  the  tool  information  delineated  by  XML  tags,  as  defined  in  the 
XML  Style  Definition  (XSD)/DTD  schema  file. 


RTO-TR-MSG-005 


4-3 


TOOLS 


•  The  extensible  Stylesheet  Language  (XSL)  file:  This  file  defines  the  rules  that  specify  how  to 
create  a  formatted  output  from  the  XML  and  the  DTD/XSD  files.  Usually,  the  XSL  file  contains 
the  style  information  to  produce  an  HTML  page.  However,  the  more  sophisticated  concept  of 
XSL  Transformation  (XSLT)  allows  for  outputs  other  than  HTML,  such  as  PDF.  It  is  important  to 
emphasize  that  the  combination  of  HTML  and  JavaScript  allows  the  programming  of  user-specific 
retrieval  functions,  such  as  sorting  on  keywords. 

Figure  8  depicts  the  top-level  view  of  the  database.  The  tool  list  consists  of  any  number  of  tools,  each  of 
which  is  characterized  by  a  Description,  its  Application  Area  (where  this  tool  can  be  of  benefit), 
and  Further  Information  (vendor  information,  POC,  etc.)  For  a  detailed  description  of  the  database 
schema,  refer  to  Annex  E. 


FEDEP  Step  (incl.  Group 
mennber  responsible  fior 
entry) 


Figure  8:  A  FEDEP  Support  Tool  is  an  Element  of  the  Tool  List  and  is  Characterised 
by  a  Description,  Application  Area  Data  and  Further  Information. 


4.5  DATABASE  USE 

4.5.1  Providing  Database  Access  to  Federation  Developers 

Since  the  tool  list  is  represented  in  XML,  the  format  is  not  easily  readable  or  searchable  without  a 
Graphical  User  Interface  (GUI).  The  database  development  software  that  was  used  to  create  the  tool  list 
provides  one,  and  it  can  be  used  to  search  the  tool  list;  however,  the  development  software  is  expensive 
and  is  intended  for  database  creation  rather  than  end-user  access.  The  database  tool  also  requires  end-users 
to  have  local  access  to  the  database,  making  centralized  updates  impossible;  it  also  prevents  database 
developers  from  having  control  over  end-user  access  to  the  raw  data.  Thus,  expecting  every  person  that  is 
interested  in  searching  the  tool  list  to  purchase  the  database  development  software  is  not  a  realistic 
solution. 

A  much  better  approach  is  to  have  the  XML  database  hosted  on  a  web  site  and  to  provide  end-users  access 
to  it  via  a  web-based  GUI.  The  GUI  would  simply  be  downloaded  from  the  same  web  site  whenever 
someone  visited  to  search  for  tool  information.  The  database  could  also  be  updated  remotely  by  providing 
database  developers  with  password-protected  access. 

Unfortunately,  the  schedule  and  resources  available  to  MSG-005  did  not  permit  the  development  of  a  GUI 
or  the  hosting  of  the  database  on  a  web  site.  It  is  a  substantial  undertaking  and  requires  careful  planning. 
For  instance,  the  GUI  should  be  developed  in  conjunction  with  the  hosting  of  the  database  for  several 
reasons.  The  GUI  may  need  to  consider:  the  graphic  standards  used  by  the  hosting  site  (to  ensure  a 
consistent  “look  and  feel”);  password  protection  and  firewall  systems  in  place;  the  software  tools  used  by 
support  staff  at  the  hosting  site;  etc. 

The  future  NATO  Simulation  Resources  Library  would  be  an  ideal  site  to  host  the  tool  list  when  the 
library  is  implemented.  Related  information  will  be  available  on  the  same  site  and  the  software  required  to 
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support  other  library  functions  will  probably  be  more  than  adequate  for  supporting  the  tool  database.  In  the 
meantime,  nations  are  being  polled  to  develop  the  GUI  and  host  the  tool  list  on  their  own  web  sites  as  a 
Voluntary  National  Contribution  (VNC). 

Wherever  the  tool  list  is  eventually  hosted,  the  Task  Group  recommends  that  access  to  it  be  unlimited. 
The  data  is  neither  classified  nor  company  confidential  since  it  is  publicly  available. 

4.5.2  Presentation  Proposal  and  Services 

Assuming  that  a  GUI  will  be  developed  at  some  point,  the  Task  Group  recommends  the  following: 

•  The  GUI  should  provide  the  following  search  criteria  as  a  minimum: 

•  The  name  of  a  tool 

•  The  name  of  the  developer/vendor/provider  company/organisation  responsible  for  a  tool 

•  The  main  functional  area  to  which  a  tool  may  apply  (its  category  of  use) 

•  The  FEDEP  step(s)  to  which  a  tool  may  apply 

•  The  availability  of  a  tool  (GOTS,  COTS,  freeware,  shareware,  etc.) 

As  the  list  is  not  expected  to  grow  to  more  than  200  entries,^  it  appears  unnecessary  to  enable  a 
search  or  sort  on  all  of  the  entry  fields. 

•  A  single  generic  tool  page  should  be  created  that  dynamically  loads  tool  information  from  the 
XML  database.  Each  tool  property  should  be  placed  in  a  data  field  next  to  an  appropriate  label. 

•  Generic  tool  pages  should  contain  field  names  that  are  also  links  to  popup  annotations.  These 
annotations  will  provide  additional  data  describing  what  each  term  means  and  provide  illustrative 
examples. 

•  Tool  pages  should  contain  an  e-mail  link  to  a  point  of  contact  for  the  tool  to  facilitate  requests  for 
additional  information. 

•  By  selecting  a  company  or  organisation  name,  a  complete  list  of  their  tools  is  presented. 

•  By  selecting  a  FEDEP  step,  a  list  of  all  tools  that  support  the  step  is  presented. 

•  By  selecting  a  category  of  tools,  a  list  of  all  tools  in  that  category  is  presented. 

•  After  selecting  a  specific  tool,  a  convenient  means  is  available  to  find  alternative  tools  from  the 
same  category  and  which  support  the  same  FEDEP  step. 

4.5.3  Update/Maintenance  of  the  Tool  Database 

Regardless  of  which  organisation  maintains  the  tool  list,  MSG-005  suggests  that  it  provide  a  means  of 
enabling  vendors  to  change  their  tool  information.  Vendors  should  not  be  able  to  upload  new  information 
directly;  instead,  they  should  submit  requested  changes  to  a  decision  authority  that  reviews  and  validates 
them.  The  decision  authority  should  ensure  that  all  changes  are  factual  and  not  subjective.  For  example, 
the  authority  should  reject  overt  marketing  information  that  a  company  wishes  to  add. 


4.6  DATABASE  ANALYSIS 

One  of  the  objectives  of  the  Task  Group  was  to  evaluate  how  well  the  tools  in  the  database  meet  the  needs 
of  federation  developers.  Since  the  Task  Group  wished  to  make  its  results  broadly  applicable  rather  than  to 
focus  on  the  needs  of  a  particular  federation,  it  decided  to  analyse  the  tools  based  on: 


^  By  mid-2003,  the  list  contains  less  than  100  tools. 
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•  their  applicability  to  the  seven  steps  of  the  IEEE  1516.3©  version  of  the  FEDEP  (see  Reference 
A.3-9),  and 

•  their  coverage  of  eight  “application  areas”,  each  of  which  may  overlap  several  FEDEP  steps  or  be 
a  special  case  within  one  of  the  steps. 

These  analyses  are  described  separately  below. 

4.6.1  Tool  List  Categorised  by  IEEE  FEDEP  Step(s) 

Each  entry  in  the  tool  database  contains  the  FEDEP  step(s)  to  which  the  tool  applies.  By  searching  the 
database  and  counting  the  number  of  tools  that  are  applicable  to  each  step,  the  steps  that  are  well 
supported  by  tools,  and  those  that  are  not,  become  apparent. 

The  Task  Group  performed  such  an  analysis  in  February  2003  and  reported  the  results  at  the  SISO  Spring 
2003  SIW  [A.4-1].  At  the  time,  the  database  contained  79  tools.  Figure  9  presents  the  results  based  on  the 
different  combinations  of  steps  that  the  tools  supported.  For  instance,  only  1  tool  supported  Steps  1 
through  3,  11  supported  Steps  3  and  4,  etc.  Clearly,  the  vast  majority  of  tools  are  applicable  to  more  than 
one  step,  the  only  exception  being  3  tools  that  only  support  Step  4.  The  largest  group  (containing  26  tools) 
supported  Steps  4  through  6,  which  suggests  that  these  steps  probably  have  similar  tool  requirements. 


Tool  List  categorised  by  FEDEP  Step  Groups 
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Figure  9:  Tool  List  Categorised  by  Groups  of  IEEE  1516.3©  FEDEP  Steps. 


Figure  10  presents  the  results  of  the  analysis  in  the  form  of  a  “radar  diagram”.  Experience  has  shown  that 
this  type  of  diagram  is  the  best  for  depicting  the  relative  level  of  tool  support  for  the  various  FEDEP  steps. 

The  radar  diagram  has  an  axis  emanating  from  its  centre  for  each  FEDEP  step,  and  each  axis  is  labelled 
with  the  step  number  in  square  brackets.  A  point  is  plotted  along  each  axis  to  indicate  how  many  tools  are 
applicable  to  the  step,  the  distance  from  the  centre  indicating  how  many.  Each  point  is  also  labelled  with 
the  number  of  tools  (in  bold  font).  The  concentric  rings  provide  a  scale;  the  number  of  tools  that  each  ring 
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represents  is  shown  beside  the  axis  corresponding  to  FEDEP  Step  1.  Note  that  the  value  for  the  outermost 
ring  (80)  is  slightly  more  than  the  number  of  tools  in  the  database  (79).  Points  on  adjacent  axes  are  joined 
by  lines,  which  result  in  the  polygon  shown.  The  position  of  the  polygon  (or  to  be  more  precise,  the 
positions  of  its  vertices)  relative  to  the  centre  of  the  diagram  indicates  any  bias  of  the  tools  towards 
particular  FEDEP  steps. 

As  seen  in  the  Figure  10,  the  available  tools  indicate  a  strong  bias  towards  FEDEP  Steps  4,  5  and  6,  that  is, 
development  through  execution.  This  strong  support  is  not  too  surprising  considering  that  the  activities 
involved  in  these  steps  (develop,  integrate,  execute,  etc.)  involve  relatively  well-defined  software  and 
hardware  development  functions.  The  software  development  area  is  also  one  in  which  it  is  usually  quite 
easy  to  market  specialized  software  tools.  Some  tools  may  even  have  their  origins  in  tools  that  were 
created  by  software  developers  to  support  their  own  federation  development  activities. 


Figure  10:  Number  of  Tools  Available  for  Each  of  the  Seven  IEEE  1516.3©  FEDEP  Steps. 

Unlike  the  support  for  Steps  4  to  6,  Steps  1,  2  and  7  {Define  Federation  Objectives,  Perform  Conceptual 
Analysis,  and  Analyze  Data  and  Evaluate  Results,  respectively)  are  barely  supported  by  tools  at  all, 
with  no  more  than  3  tools  available  for  each  one.  The  lack  of  support  is  surprising  but  weak  support  could 
have  been  expected  at  least  for  Steps  1  and  2:  both  involve  relatively  “soft”  activities  (defining  objectives 
and  performing  conceptual  analysis)  which  are  less  well-defined  than  those  associated  with  Steps  4  to  6. 
Thus,  tool  requirements  are  more  vague  which  discourages  their  development.  Step  1  and  2  activities  are 
also  relatively  independent  of  HLA  considerations  (compared  to  federation  development  and  execution) 
and  may  be  adequately  handled  by  general-purpose  requirements  capture  tools. 
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Lack  of  support  for  Step  7  (data  analysis)  is  more  surprising  than  for  Steps  1  and  2  because  data  analysis  is 
likely  to  require  standard  mathematical  and  database  query  functions,  all  of  which  are  well-defined. 
One  possible  explanation  is  Step  7  activities,  such  as  those  for  Steps  1  and  2,  are  relatively  independent  of 
HLA  considerations  and  general-purpose  analysis  tools  may  again  be  proving  adequate.  Another  possible 
reason  for  the  lack  of  tools  explicitly  supporting  Step  7  may  be  that  this  step  did  not  exist  in  the  former 
versions  of  the  FEDEP  (including  US  DoD  Version  1.5);  it  was  only  identified  during  the  development  of 
the  recent  IEEE  version. 

Step  3,  federation  design,  is  supported  by  22  tools.  While  not  as  many  as  for  Steps  4  to  6,  the  number  is 
considered  adequate  because  federation  design  is  not  likely  to  require  as  many  tools  as  federation 
development,  integration,  and  execution. 

4.6.2  Tool  List  Categorised  by  Application  Area 

The  above  analysis  evaluated  tool  availability  based  on  the  FEDEP  steps.  While  valuable  to  people  who 
are  working  on  a  particular  step,  it  ignores  overlapping  requirements  that  are  shared  by  multiple  steps  and 
does  not  take  into  consideration  how  well  a  tool  supports  each  step. 

To  offer  an  alternative  perspective  on  HLA  tools,  tool  support  for  eight  different  application  areas  was 
analysed.  Each  area  represents  a  categorisation  of  tools  with  little  or  no  regard  for  the  FEDEP  steps; 
in  fact,  each  application  area  may  overlap  several  FEDEP  steps  or  be  a  specialised  area  within  one  of  the 
steps. 

The  application  areas,  derived  from  the  NIAG  Report  [A.2-2],  are  as  follows: 

•  FedDev:  A  tool  in  this  category  can  be  used  during  FEDEP  Steps  4  or  5  to  create  software  or  data 
that  is  eventually  used  during  federation  execution,  or  to  provide  support  functions  such  as 
managing  software  requirements  and/or  test  and  integration.  A  tool  that  produces  software  or 
databases  that  are  used  during  federation  execution  also  supports  the  FedEx  category  (described 
below). 

•  NatEnvGen:  Tools  in  this  category  can  be  used  to  create  or  edit  synthetic  natural  environments 
such  as  terrain  data,  visual  models,  etc.  Assuming  that  the  resulting  synthetic  natural 
environments  are  used  during  FEDEP  Steps  4  to  6,  a  tool  that  supports  the  NatEnvGen  category 
also  supports  the  FedDev  (Steps  4  and  5)  and  FedEx  (Step  6)  categories;  it  may  also  support  other 
categories  such  as  AAR  (Step  7). 

•  ScenDev:  A  tool  that  supports  the  ScenDev  category  can  be  used  to  help  develop  an  exercise 
scenario,  such  as  providing  planning  tools  for  force  deployment  and  testing  entity  interactions 
(Steps  2  to  5).  A  tool  that  supports  the  NatEnvGen  category  but  only  creates  natural  environments 
or  visual  equipment  models  is  not  considered  supportive  of  the  ScenDev  category. 

•  FedEx:  A  tool  in  this  category  is  used,  or  produces  software  or  databases  that  are  used,  during 
federation  testing  and  execution  (Steps  5  and  6).  For  instance,  RTI  software  supports  this 
category. 

•  Viewers:  In  this  category,  the  tool  provides  a  2D  or  3D  view  of  exercise  synthetic  environments, 
such  as  terrain  and  equipment  visual  models.  The  tool  must  be  usable  during  one  or  more  of 
FEDEP  Steps  4  to  7.  Tools  that  incorporate  2D  or  3D  viewers  to  manipulate  data  off-line  (such  as 
equipment  visual-model  editors)  are  not  considered  supportive  of  this  category. 

•  AAR:  This  category  indicates  that  the  tool  is  designed  to  support  After  Action  Review  activities, 
including  data  collection  during  federation  test  and  execution  (Steps  5  to  7).  In  the  case  of  a 
general-purpose  tool,  it  is  likely  to  be  used,  or  can  produce  software  or  databases  to  be  used, 
during  AAR. 
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•  CCIS_IF:  In  this  category,  the  tool  is  designed  to  support  interfacing  simulations  to  Command 
and  Control  Information  Systems  (CCIS)  (Steps  4  to  6).  In  the  case  of  a  general-purpose  tool,  it  is 
likely  to  be  used,  or  can  produce  software  or  databases  to  be  used,  to  help  interface  simulations  to 
CCIS. 

•  VV:  Tools  in  this  category  are  designed  to  support  verification  and/or  validation  (V&V)  activities 
(Steps  1  to  7).  In  the  case  of  a  general-purpose  tool,  it  is  likely  to  be  used,  or  can  produce  software 
or  databases,  for  V&V  activities. 

Before  evaluating  the  tool  availability  in  these  application  areas,  the  Task  Group  decided  to  take  into 
consideration  the  degree  of  support  for  each  area  since  support  can  vary  dramatically  from  one  tool  to  the 
next.  As  a  result,  the  following  four  support  ratings  were  used:  none,  minimal,  partial,  and  substantial. 
Admittedly,  each  tool  rating  is  very  subjective  but  this  approach  was  considered  substantially  better  than  a 
binary  yes/no  rating.  Unfortunately,  a  quantitative  rating  based  on  a  thorough  analysis  of  each  tool  was 
simply  not  feasible  given  the  time  available  and  the  number  of  tools  to  be  rated. 

In  June  2003,  the  Task  group  rated  how  much  support  each  of  the  79  tools  in  the  database  provided  to  the 
application  areas.  Table  2  presents  the  results. 

The  value  of  the  subjective  rating  becomes  evident  when  the  fifth  and  sixth  (that  is,  the  third-  and  second- 
last)  columns  are  compared.  The  number  of  tools  that  provide  substantial  coverage  (in  the  fifth  column) 
is  usually  much  less  than  half  the  number  that  provides  minimal  or  more  support  (in  the  sixth). 
This  difference  is  very  significant  and  it  would  not  be  evident  if  a  binary  scale  had  been  used. 
For  instance,  with  a  binary  scale,  the  table  would  have  indicated  that  41  tools  were  available  for  VV 
activities.  The  fact  that  only  2  provided  substantial  support  would  have  been  less  evident. 

Figure  1 1  provides  a  graphical  view  of  the  Table  2  results.  It  indicates  the  percentage  of  the  total  number 
of  tools  in  the  database  that  provide  the  different  levels  of  support  for  each  application  area. 


Tool  List  categorised  by  Support  Rating  and 
Appiication  Areas 


■  Substantial 

□  Partial 

□  Minimal 

□  None 


Figure  11:  Tool  List  Categorised  by  Application  Area. 
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Table  2:  Tool  List  Categorised  by  Application  Area  and  Support  Rating 


Application 

Area 

Number  of  Tools  for  Each  Level  of  Support 

None 

Minimal 

Partial 

Substantial 

Minimal  or 
More 

Partial 
or  More 

FedDev 

5 

12 

45 

17 

74 

62 

NatEnvGen 

61 

3 

5 

10 

18 

15 

Seen  Dev 

44 

15 

11 

9 

35 

20 

FedEx 

7 

13 

33 

26 

72 

59 

Viewers 

53 

10 

1 

15 

26 

16 

AAR 

35 

24 

15 

5 

44 

20 

CCISJF 

68 

7 

3 

1 

11 

4 

W 

38 

22 

17 

2 

41 

19 

Regarding  which  application  areas  are  well  covered,  federation  development  and  execution  have  the  most 
support  with  approximately  60  tools  each  providing  at  least  partial  or  substantial  support  (as  seen  in  the 
rightmost  column  of  Table  2).  Both  areas  are  well  supported  just  by  those  tools  providing  substantial 
support,  that  is,  federation  development  by  17  and  execution  by  26. 

Natural  environment  generation  and  scenario  development  are  also  well  supported  with  15  and  20  tools, 
respectively,  providing  partial  or  substantial  support.  Given  the  number  of  Geographic  Information 
Systems  (GIS)  and  related  applications  available  in  the  marketplace,  presumably  many  more  tools  are 
available  for  natural  environment  generation. 

The  viewer  category  is  also  well  supported,  with  15  tools  providing  substantial  support.  Relatively  few 
tools  in  this  category  provide  minimal  or  partial  support,  indicating  that  tools  that  support  this  category  are 
specifically  designed  for  it. 

The  distribution  of  tool  support  for  AAR  and  VV  is  similar.  Both  have  more  than  40  tools  providing 
minimal  or  better  support,  but  only  a  handful  provides  substantial  support.  Since  the  majority  of  the 
40-plus  tools  provide  only  minimal  or  partial  support  in  both  areas,  the  support  may  be  more  by  accident 
than  design.  As  an  example,  several  stealth  viewers  were  rated  as  providing  partial  support  for  AAR  and 
VV  because  they  do  not  provide  any  features  that  are  specifically  designed  for  these  areas. 

The  CCIS  IF  area  is  the  least  well-supported  area.  Only  11  tools  are  available  even  when  those  with 
minimal  support  are  included;  in  fact,  only  1  provided  substantial  support.  One  explanation  is  CCIS  IF 
is  probably  the  most  specialised  area  of  the  eight  and  so  customised  software  solutions,  rather  than  an 
off-the-shelf  tool,  are  required  to  handle  the  complex  problems  that  arise.  Thus,  tool  support  can  be 
expected  to  be  minimal. 

Overall,  the  first  five  application  areas  appear  to  be  well  supported;  the  last  three  are  not.  The  lack  of  tools 
for  the  CCIS  IF  area  is  understandable  given  how  specialised  it  is;  however,  the  lack  of  tools  providing 
substantial  support  for  AAR  and  VV  is  somewhat  surprising.  One  possible  explanation  is  that  general- 
purpose  tools  are  being  used  and  proving  adequate.  Unfortunately,  this  cannot  be  determined  from  the 
database. 
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Chapter  5  -  CONCLUSIONS  AND  RECOMMENDATIONS 

5.1  CONCLUSIONS 

MSG-005  Task  Group  has  successfully  accomplished  its  mission  to  identify  tools  that  support  the  various 
steps  of  the  IEEE  1516.3©  FEDEP.  To  date,  a  total  of  79  tools  have  been  identified  and  catalogued  in  the 
MSG-005  database.  The  largest  number  of  these  tools  support  FEDEP  Steps  4,  5,  and  6  {Develop 
Federation]  Plan,  Integrate  and  Test  Federation]  and  Execute  Federation  and  Prepare  Outputs] 
respectively),  while  no  more  than  three  tools  support  Steps  1,  2  and  7  {Define  Federation  Objectives, 
Perform  Conceptual  Analysis,  and  Analyze  Data  and  Evaluate  Results,  respectively).  The  Task  Group 
anticipates  an  improvement  in  this  situation  with  the  availability  of  additional  tools  from  the  EUCLID 
RTP  11.13  programme,  which  will  demonstrate  its  capabilities  in  November  2003. 

The  lack  of  availability  of  tools  should  not  be  viewed  as  a  negative,  however.  This  project  represents  the 
first  time  that  an  analysis  of  available  tools  has  taken  place,  and  it  has  pointed  out  deficiencies  and 
possible  opportunities  for  further  tool  developments.  With  the  information  contained  in  this  single  source, 
federation  managers  will  be  able  to  rapidly  identify  tools,  their  capabilities  and  the  sources  for  additional 
information. 


5.2  RECOMMENDATIONS 

Generating  a  database  of  tools  that  support  the  FEDEP  is  only  the  first  step  in  creating  and  maintaining  a 
viable  product  for  the  NATO  Modelling  and  Simulation  community.  The  issues  of  dissemination  and 
maintenance  need  to  be  addressed.  The  information  contained  in  this  report  is  dynamic  and  will  require 
periodic  update  if  the  product  is  to  remain  valuable.  In  addition,  there  may  be  vendors  that  were  not 
available  to  the  Task  Group  that  will  want  to  contribute  tool  information  to  the  database  in  the  future. 
Therefore,  the  MSG-005  Task  Group  recommends  that: 

1)  The  NMSG  implement  the  recommendations  made  by  this  Task  Group  in  November  2001  to 
request  funding  support  from  the  RTA  to  create  a  web-based  capability  to  access  and  maintain  the 
tool  database. 

2)  As  an  interim  solution,  the  NMSG  permit  the  hosting  and  support  of  the  tool  database  on  a  web 
site  through  Voluntary  National  Contributions  (VNC). 

3)  The  NMSG  create  a  follow  on  Task  Group  responsible  for  meeting  on  an  annual  or  semi-annual 
basis  to  review  and  update  the  information  contained  in  the  FEDEP  tool  database. 

4)  The  follow-on  Task  Group  publish  an  addendum  to  this  report  and  update  the  FEDEP  tool 
database  when  the  RTP  11.13  tools  become  available. 

5)  The  NMSG  approve  this  report,  implement  the  recommendations  and  provide  the  necessary 
oversight. 
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Acronym 

Meaning 

AAR 

After  Action  Review 

ACE 

Allied  Command  Europe 

ACSTP 

ACE  Command  and  Staff  Training  Programme 

AMG 

HLA  Architecture  Management  Group 

CAX 

Computer  Assisted  Exercise 

CCIS 

Command,  Control  and  Intelligence  System  (C2I  Systems) 

CEPA 

Common  European  Priority  Area  (EUCLID) 

CEP 

Call  For  papers 

CGE 

Computer  Generated  Forces 

CIS 

Communication  Information  System 

CITE 

Combined-Joint  Task  Force 

CNAD 

Conference  of  National  Armament  Directors 

ConOps 

COTS 

Concept  of  Operations 

Commercial-Off-The-Shelf 

CRO 

Crisis  Response  Operations 

C2I 

Command,  Control  and  Intelligence 

C3I 

Command,  Control,  Communications  &  Intelligence 

DIE 

Data  Interchange  Format 

DiMuNDS 

Distributed  Multi-National  Defence  Simulation 

DMSO 

Defense  Modeling  &  Simulation  Office  (US  DoD) 

DoD 

U.S.  Department  of  Defense 

DST 

Decision  Support  Tool 

DTD 

Document  Type  Definition  (XML) 

DTED 

Digital  Terrain  Elevation  Data 

EUCLID 

European  Co-operation  for  the  Long  term  In  Defence 

FDD 

FOM  Document  Data 

FED 

Federation  Execution  Data 

FEDEP 

Federation  Development  and  Execution  Process  (HLA) 

RTO-TR-MSG-005 


ANNEX  C  -  LIST  OF  ACRONYMS 


FEPW 

FOM 

CIS 

GOTS 

GUI 

HI,  A 

HQ 

HTML 

ICT 

IEEE 

JALLC 

LAN 

MC 

MG 

MSCO 

MSIAC 

MSMP 

M&S 

NAG 

NATO 

NFDT 

NIAG 

NMSG 

OMDT 

OML 

OMT 


Federation  Execution  Planners’  Workbook 
Federation  Object  Model  (HLA) 

Geographic  Information  System 
Govemment-Off-The-  Shelf 
Graphical  User  Interface 

High  Level  Architecture  (US  DoD  Standard  1.3  (1998)  and  IEEE  Standard  1516 
(2000  to  2003)) 

Headquarters 

Hyper  Text  Mark-up  Language 

Initial  Common  Tools 

Institute  of  Electrical  and  Electronic  Engineers 
Joint  Analysis  Lessons  Learned  Centre 

Local  Area  Network 

NATO  Military  Committee 
Management  Group  (EUCLID) 

Modelling  &  Simulation  Co-ordination  Office  (NATO) 

Modeling  and  Simulation  Information  Analysis  Center  (U.S.) 

Modelling  and  Simulation  Master  Plan  (NATO  and  US  DoD) 

Modelling  &  Simulation 

North  Atlantic  Council 

North  Atlantic  Treaty  Organization 

National  Federate  Development  Team  (PADEP) 

NATO  Industry  Advisory  Group 
NATO  Modelling  and  Simulation  Group 

Object  Model  Development  Tool 
Object  Model  Library 
Object  Model  Template 
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m%\ 

pa 


PADEP 

PathFinder  Development  and  Execution  Process 

PDF 

Portable  Document  Format  (Adobe®) 

PfP 

Partnership  (or  Partners)  for  Peace 

POC 

Point  Of  Contact 

POW 

Programme  Of  Work 

PROC 

Federation  Development  Process  Forum  of  SISO 

PSG 

Pathfinder  Steering  Group 

RID 

RTI  Initialisation  Data 

RTA 

Research  and  Technology  Agency  (NATO) 

RTB 

Research  and  Technology  Board  (NATO) 

RTI 

Run-Time  Infrastructure  (HLA) 

RTO 

Research  and  Technology  Organisation  (NATO) 

RTP 

Research  and  Technology  Project  (EUCLID) 

R&D 

Research  and  Development 

SAC 

Standards  Activity  Committee  (SISO) 

SE 

Synthetic  Environment 

SEDEP 

Synthetic  Environment  Development  and  Execution  Process  (EUCLID  RTP  11.13) 

SGMS 

Steering  Group  for  M&S  (NATO) 

SISO 

Simulation  Interoperability  Standards  Organization 

SIW 

Simulation  Interoperability  Workshop  (SISO) 

SOM 

Simulation  Object  Model  (HLA) 

SRL 

Simulation  Resources  Library  (SRL) 

STANAG 

Standardisation  Agreement  (NATO) 

TAP 

Technical  Activity  Programme  (RTO) 

TEEP 

The  PfP  Training  and  Education  Enhancement  Programme 

TG 

Task  Group  (RTO) 

TOR 

Terms  Of  Reference  (RTO) 

UK 

United  Kingdom 

US 

United  States  of  America 

VNC 

Voluntary  National  Contribution 

VV&A 

Verification,  Validation,  and  Accreditation 

V&V 

Verification  and/or  Validation 
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WAN 

Wide  Area  Network 

WE 

Working  Element  (EUCLID  RTF  11.13) 

WEAG 

Western  Europe  Armament  Group 

XML 

extensible  Mark-up  Language 

XSD 

XML  Style  Definition 

XSL 

extensible  Stylesheet  Language  (XML) 

XSLT 

XSL  Transformation  (XML) 

2D 

Two-dimensional 

3D 

Three-dimensional 
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D.l  PATHFINDER  DEVELOPMENT  AND  EXECUTION  PROCESS  (PADEP) 

The  PathFinder  Development  and  Execution  Process  (PADEP)  is  the  result  of  tailoring  the  Federation 
Development  and  Execution  Process  (FEDEP)  Version  1.5  (described  in  Chapter  2  and  Reference  A.3-1) 
to  meet  the  particular  needs  of  the  PathFinder  programme. 

The  PADEP,  as  described  in  Appendix  B  of  the  NIAG  Phase  2  Report  [A.2-2],  was  further  extended  in 
the  NIAG  final  report  [A.2-3].  For  example,  federation  management  issues  are  described,  step-by-step, 
in  Chapter  5  and  the  PathFinder  task  list  is  summarised  in  the  annex. 

The  PADEP  consists  of  six  major  steps.  The  documents  to  be  generated  in  the  PADEP  and  their 
interconnections  are  shown  in  Figure  Dl. 


Figure  D1:  PADEP  -  Documents  and  their  interconnections. 


D.2  SYNTHETIC  ENVIRONMENT  DEVELOPMENT  AND  EXPLOITATION 
PROCESS  (SEDEP) 

D.2.1  Introduction 

The  Synthetic  Environment  Development  &  Exploitation  Process  (SEDEP)  originated  as  part  of  a  major 
European  research  initiative,  European  Co-operation  for  the  Long-term  In  Defence  (EUCLID)  Research 
and  Technology  Project  (RTP)  11.13.  EUCLID  RTP  11.13  was  established  to  identify  and  overcome 
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obstacles  which  prevent  SEs  being  exploited  within  and  across  European  nations.  This  was  achieved  by 
developing  a  common  process  (that  is,  the  SEDEP)  underpinned  with  an  integrated  software  tool  suite  to 
reduce  the  cost  and  timescale  of  specifying  and  developing  SE  applications.  The  SEDEP  is  based  on  the 
Federation  and  Development  and  Execution  Process  (FEDEP),  which  has  been  extended  and  enhanced  to 
satisfy  the  wider  needs  of  the  SE  community. 

For  the  purpose  of  the  SEDEP,  the  term  “Synthetic  Environment”  means  the  integration  of  models, 
simulations,  people  and  real  equipment  into  a  common  representation  of  the  world  and  is  synonymous 
with  the  FEDEP  term  “federation”.  The  term  “SE”  is  more  commonly  used  by  the  users  of  simulations, 
whilst  the  term  “federation”  is  used  more  by  the  developer  community.  In  the  following  description, 
the  more  appropriate  term  is  used  according  to  the  context  in  which  it  is  used. 

The  purpose  of  the  SEDEP  is  to: 

•  Encourage  use  of  SE  technology  to  benefit  different  application  domains,  such  as  equipment 
acquisition,  training,  etc. 

•  Provide  guidance  to  developers  and  users  to  help  them  plan  and  perform  the  different  activities 
necessary  to  produce  the  required  products  and  results. 

•  Promote  good  practice  for  developing  SEs  on  time  and  within  budget. 

•  Promote  re-use  of  products  (federations,  federates,  components,  etc.)  and  results. 

•  Provide  a  framework  for  a  tool  set  to  reduce  the  cost  and  time  for  creating  and  utilising  SEs. 


D.2.2  SEDEP  Overview 

The  SEDEP  contains  eight  steps  as  shown  in  Figure  D2,  with  each  step  consisting  of  a  number  of 
activities.  In  addition,  each  step  has  its  own  feedback  loops  and  multiple  internal  iterations  may  be 
performed  without  interfacing  to  other  steps.  The  interfaces  between  steps  are  more  formal  and  occur  less 
frequently  than  between  activities  within  a  step. 


Steps 


Define  Fed.  User  Requirements 


Define  Fed.  System  Requirements 


Design  Federation 


O 

& 

Pi 


Analyse  User’s  Needs 


Operate  Federation 


Perform  Evaluation 


^=>  Data  Flow 


Products 

User  Needs  Analysis  Documents 

User  Requirements  Documents 

System  Requirements  Documents 

Design  Documents 

gppsQ 

- 

Federation  Components 

QQDQ 

Federation  Ready  for  Operation 

- 

Federation  Execution  Data 

Evaluation  Results 

Process  Flow 

Figure  D2:  SEDEP  Steps  and  Products. 
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Two  complementary  representations  (“views”)  are  used  to  describe  the  SEDEP: 

•  Steps  Representation:  In  this  view,  the  various  activities  are  organised  into  sequential  steps 
along  the  whole  process.  Each  one  covers  a  specific  phase  of  the  SE  lifecycle. 

•  Overlays  Representation:  In  this  view,  the  different  activities  of  the  process  are  thematically 
organised  into  overlays.  Each  one  covers  a  specific  theme  or  aspect  of  the  SE,  which  requires  a 
specific  technical  environment  and/or  special  expertise. 

A  software  tool  suite,  including  a  repository,  underpins  the  SEDEP  process.  The  Repository  Software 
Architecture  serves  two  purposes,  that  is,  to  store  information  about  existing  SE  assets  (such  as  simulation 
systems,  databases,  etc.)  to  promote  re-use,  and  to  store  data  generated  by  a  SEDEP  step/activity  so  that  it 
is  available  as  input  to  other  steps/activities. 

An  important  aspect  of  the  SEDEP  is  that  it  may  be  used  iteratively.  This  means  that  it  may  be  initiated 
several  times  for  a  particular  SE  project  and  that  successive  iterations  build  on  the  information  already 
available.  The  SEDEP  is  tailored  for  each  iteration  to  meet  the  requirements  of  the  objective  of  the 
iteration.  This  means  that  for  some  iterations,  some  activities  are  performed  to  a  low  level  of  detail  or  even 
not  performed  at  all.  An  important  aspect  of  the  tailoring  is  the  specification  of  the  particular  tools  used  to 
support  the  different  activities. 

Although  the  steps  are  shown  as  sequential,  in  practice,  the  steps  may  run  concurrently  with  one  step 
starting  before  the  proceeding  one  has  finished.  Feedback  loops  are  used  where  it  may  be  necessary  to 
revisit  an  earlier  step  as  a  result  of  actions  performed  in  later  ones. 

The  SEDEP  steps  are: 

•  Step  0:  Analyse  User’s  Needs.  The  aim  of  this  step  is  to  define  and  analyse  user  needs  in  order  to 
understand  what  results  the  SE  should  provide  and  the  purpose  of  the  current  SEDEP  iteration. 
This  information  enables  the  SE  systems  engineer  to  plan  how  the  SEDEP  iteration  should  be 
performed.  The  project  planning  not  only  includes  traditional  project  management  planning 
activities  but  also  tailoring  the  process  to  satisfy  the  requirements  of  the  SEDEP  iteration. 
An  important  outcome  of  the  analysis  is  to  determine  the  scope  of  re-use,  which  can  dramatically 
reduce  the  cost  of  the  SE  by  identifying  relevant  existing  SE  knowledge  and  assets. 

•  Step  1:  Define  Federation  User  Requirements.  The  purpose  of  this  step  is  to  turn  the  loosely 
defined  user  needs  into  a  complete  and  unambiguous  specification  of  the  user’s  requirements  for 
the  federation.  The  specification  contains  three  elements:  atomic  user  requirement  statements, 
the  scenario(s)  to  be  run  on  the  federation,  and  the  evaluation  objectives  of  the  user. 

•  Step  2:  Define  Federation  System  Requirements.  The  purpose  of  this  step  is  to  translate  the 
user  requirements  into  the  requirements  for  an  SE  that  will  provide  an  appropriate  representation 
of  the  real  world  for  solving  the  problem  under  investigation.  The  federation  system  requirements 
consist  of  three  elements:  a  conceptual  model,  which  provides  an  implementation  independent 
representation  of  the  federation;  atomic  system  requirement  statements;  and  the  evaluation 
definition,  which  specifies  the  criteria,  methods,  algorithms  and  data  definitions  to  be  used  in  the 
evaluation  step  to  analyse  and  evaluate  the  execution  outputs. 

•  Step  3:  Design  Federation.  The  purpose  of  this  step  is  to  identify,  evaluate,  and  select  all  the 
federation  participants  (federates),  and  to  allocate  required  functionalities  and  subsets  of  the 
scenario  pertinent  to  the  federates.  Where  no  suitable  federates  can  be  found,  existing  ones  are 
adapted  or  new  ones  designed  to  provide  the  desired  functionality.  In  addition  to  the  design 
documents,  detailed  test  plans  are  produced  for  verifying  and  validating  the  operation  of  the 
federation.  This  step  also  defines  activities  for  designing  the  databases  and  the  network  and 
computer  infrastructure  required  to  support  the  federation. 
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•  Step  4:  Implement  Federation.  The  purpose  of  this  step  is  to  produce  the  Federation  Object 
Model  (FOM),  which  describes  the  interactions  betweens  the  participants  and,  when  necessary, 
to  build  and/or  modify  federates.  Once  all  of  the  federation  elements  have  been  implemented,  unit 
testing  is  performed  so  that  they  are  ready  for  integration  and  system  testing. 

•  Step  5:  Integrate  &  Test  Federation.  The  purpose  of  this  step  is  to  integrate  the  federation 
elements  with  the  run-time  infrastructure  and  to  ensure  that  the  federation  is  ready  for  operation. 
This  includes  testing  the  interactions  between  federates,  ensuring  that  the  network  is  reliable  and 
can  handle  the  expected  traffic,  verifying  the  federation  against  the  system  requirements,  and 
validating  the  federation  against  the  user  requirements. 

•  Step  6:  Operate  Federation.  The  purpose  of  this  step  is  to  prepare  the  federation  for  operation 
and  to  run  the  federation  scenario(s).  Preparation  activities  include  training  the  federation 
instructors,  operators,  and  technicians  and  rehearsing  the  federation  executions  to  identify 
unforeseen  problems. 

•  Step  7:  Perform  Evaluation.  The  purpose  of  this  step  is  to  post-process  the  outputs  acquired 
during  the  federation  execution,  analyse  them,  and  evaluate  the  results.  The  conclusions  are  then 
fed  back  to  the  user  to  decide  if  the  problem  has  been  solved  or  whether  further  federation  runs 
are  required. 
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ORGAI4^IZATION 


This  annex  serves  as  a  guideline  for  the  manager  of  the  tool  list  who  wants  to  update  information  on  tools 
or  integrate  the  database  into  a  web  site  or  some  other  software  application. 


E.l  OVERALL  STRUCTURE 

The  overall  structure  of  the  tool  list  is  tree-like:  the  root  element,  ToolList,  contains  any  number  of  Tool 
descriptions,  each  of  which  is  characterised  by  a  number  of  attributes. 

Element  ToolList 


ToolList 


diagram 


children  Tool 


1  ..OO 


H^nne  oF  Tool  (General 
Support  vs.  HLA  specific, 
FEDEP  Step  (incl.  Group 
member  responsible  For 
entry) 


Furthermore,  each  Tool  item  contains  three  more  elements,  that  is,  a  Description,  an  ApplicationArea  and 
Furtherinformation.  As  the  picture  below  shows,  each  Tool  also  has  some  management  data  (date  of  tool 
review  and  the  name  of  reviewer)  and  information  on  whether  the  tool  is  HLA-specific  and  which  FEDEP 
steps  the  tool  supports. 


Element  ToolList/Tool 


diagram 

Description 

Tool  l^l - 

ApplicationArea  |H 

Name  oF  Tool  (General 

Support  vs.  HLA  specific, 

FEDEP  Step  (incl.  Group 
member  responsible  For 
entry) 

Furtherinformation 

children 

Description  ApplicationArea  Furtherinformation 

attributes 

Name 

Type 

Use 

Default 

Fixed 

ReviewedBy 

GroupMember 

xs:  string 

required 

ReviewDate 

xsigYear 

Month 

optional 

NameOfTool 

xs:  string 

required 

FEDEPStep 

xs:  string 

optional 

HLASpecific 

xsiNM 

TOKEN 

required 

annotation 

documentation 

Name  of  Tool  (General  Support  vs.  HLA  specific,  FEDEP  step 
(incl.  Group  member  responsible  for  entry) 
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E.2  ELEMENT:  Description 

The  Description  element  contains  three  fields:  the  Version  field  specifies  the  version  of  the  tool  that  was 
reviewed,  the  Comment  field  contains  user  review  comments,  and  the  Maturity  field  indicates  the  maturity 
of  the  tool,  such  as  the  number  of  licenses  in  use  or  how  long  the  tool  has  been  commercially  available. 

Element  ToolList/Tool/Description 


Element  ToolList/Tool/DescriptionA^ ersion 


diagram 

Version 

type 

xs:  string 

Element  ToolList/Tool/Description/Comments 


diagram 

Comments 

Benefits  (especially  HLA 
nelatetflj  Limits,  and 
description  oF  capability. 

type 

extension  of  xs: string 

attributes 

Name 

Type 

Use 

Default 

Fixed 

Userinterface 

xs:  string 

optional 

RealtimeTool 

xs:boolean 

optional 

annotation 

documentation 

Benefits  (especially  HLA  related).  Limits, 
and  description  of  capability. 

Element  ToolList/Tool/Description/Maturity 


Diagram 

Maturity 

type 

xs:  string 
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E.3  ELEMENT:  ApplicationArea 

The  ApplicationArea  element  contains  information  related  to  the  application  area  of  the  tool. 
(The  application  areas  are  described  in  Section  4.6.2  of  the  report.)  The  following  eight  subsections 
describe  the  database  elements  related  to  each  one. 


Element  T  oolList/T  ool/ApplicationArea 


FedDeu 


Does  tool  support  FEDEP 
step  4  end  5? 


HatEnuGen  | 

Does  tool  help  to 
speciF^jinnplennent  e  natural 
environment? 


diagram 


ScenDeu 


Does  tool  help  to  support 
FEDEP  step  2 


ApplicationArea  [^|— 


FedEx 


Does  tool  help  to  support 
FEDEP  steps  5  and  t? 


Viewers 


Is  tool  (tnntime)  viewer? 


"AAR 


Is  tool  an  After  Action 
Review  tool? 


Does  tool  support  coupling 
Command  and  Control 
InFomnation  Systems  (CCIS[) 
into  Federations?  (e.g. 
concept  oF  data  base 
replication,  etc.) 


"VV 


Does  tool  support  Validation 
and  Verification  oF  a 
Federation  model  and 
implementation? 


children 


FedDev  NatEnvGen  ScenDev  FedEx  Viewers  AAR  CCIS  IF  VV 


E.3.1  Element:  FedDev 

The  FedDev  leaf  captures  information  related  to  the  Steps  4  and  5  of  the  FEDEP.  A  tool  in  the  FedDev 
application  area,  as  described  in  Section  4.6.2,  can  be  used  to  create  software  or  data  that  is  eventually 
used  during  federation  execution,  or  to  provide  support  functions  such  as  managing  software  requirements 
and/or  test  and  integration. 
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The  Fed  Dev  element  contains  six  leaf  elements,  each  of  which  contains  reviewer  comments  on  whether 
the  tool  is  used  as  an  OMDT,  to  contribute  to  configuring  and/or  documenting  a  federation,  etc.  Additional 
service  layers  that  help  applications  deal  with  an  RTI  are  captured  in  the  Middleware  field. 


Element  T oolList/T ool/Application Ar ea/F edDev 


diagram 


Does  tool  help  to 
outline/document  results  oF  a 
Federation  development 
process? 


children 


OMDT  FederateDevEnv  FedConfig  Middleware  MigrationTool 

FedDevDocumentation 


annotation 


documentation 


Does  the  tool  support  FEDEP  step  4  and  5? 


Element  ToolList/Tool/ Application Area/FedDev/OMDT 


diagram 

"OMDT 

Is  tool  an  C 

)MDT? 

type 

xsiboolean 

annotation 

documentation 

Is  the  tool  an  Object  Model  Development  Tool? 
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Element  T  oolList/T  ooI/ApplicationArea/F  edDev/F  eder  ateDevEnv 


diagram 

FederateDeuEnu 

Does  tool  contribute  to 
FEDEP  step  3  to  5? 

type 

xsiboolean 

annotation 

documentation 

Is  the  tool  a  support  to  design, 
develop  and  test  a  federate? 

Element  T  oolList/T  ool/ Application  Area/F  edDev/F  edConfig 


diagram 

FedConflg 

Does  tool  suppor 
Configuretion? 

t  Federation 

type 

xsiboolean 

annotation 

documentation 

Does  tool  support  Federation  Configuration? 

Element  T  oolList/T  ool/ApplicationArea/F  edDev/Middleware 


diagram 

Middleware 

Is  tool  a  middlewai 
between  an  applies 
a  RTI? 

ne 

ition  and 

type 

xs:  string 

annotation 

documentation 

Is  the  tool  a  middleware  between 
an  application  and  a  RTI? 

Element  T  oolList/T  ool/ApplicationArea/F  edDev/Migr  ationT  ool 


diagram 

MigrationTool 

Does  tool  help  to  migi 
application  to  HLA? 

rate  an 

type 

restriction  of  xsiboolean 

annotation 

documentation 

Does  the  tool  help  to  migrate  an  application  to  HLA? 

Element  T  oolList/T  ool/ApplicationArea/F  edDev/F  edDevDocumentation 


diagram 

FedDeuDocumentation 

Does  tool  help  to 
outline/document  results  oF  a 
Federation  development 
process? 

type 

xsiboolean 

annotation 

documentation 

Does  tool  help  to  outline/document  results 
of  a  federation  development  process? 
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E.3.2  Leaf:  NatEnvGen 

The  NatEnvGen  leaf  contains  reviewer  comments  on  how  the  tool  can  be  used  to  create  or  edit  synthetic 
natural  environments,  such  as  terrain  data,  visual  models,  etc. 


Element  T oolList/T ool/ Application Area/N atEnvGen 


diagram 

HatEnuGen 

Does  tool  help  to 
speciFy/implemen 
environment? 

t  a  natural 

type 

xs:  string 

annotation 

documentation 

Does  the  tool  help  to  specify/implement 
a  synthetic  natural  environment? 

E.3.3  Leaf:  ScenDev 

The  ScenDev  leaf  contains  reviewer  comments  on  how  the  tool  can  be  used  to  help  develop  an  exercise 
scenario,  such  as  providing  planning  tools  for  force  deployment  and  testing  entity  interactions  (in  FEDEP 
Step  2). 

Element  T oolList/T ool/ Application Area/ScenDev 


diagram 

ScenDev 

Does  tool  help 
FEDEP  step  ? 

to  support 

type 

xs:  string 

annotation 

documentation 

Does  tool  help  to  support  FEDEP  step  2  to  5? 

E.3.4  Element:  FedEx 

The  FedEx  element  contains  seven  leaf  elements.  They  are  used  to  describe  how  the  tool  can  be  used,  or 
can  produce  software  or  databases  to  be  used,  during  federation  testing  and  execution  (FEDEP  Steps  5  and 
6).  Here,  issues  like  controlling  a  federation,  collection  of  data,  documentation  and  general  support  are 
addressed.  Security  issues  are  also  covered  here. 
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Element  T  oolList/T  ooI/ApplicationArea/F  edEx 


diagram 


Is  tool  a  security  device? 


children 


FedCtrl  Performance  RTI  F edExDocumentati on  DataCollect  NetworkSptDevice 
SecurityDevice 


annotation 


documentation 


Does  tool  help  to  support  FEDEP  steps  5  and  6? 


Element  T oolList/T ool/ Application Area/FedEx/FedCtrl 


diagram 

"Fedarl 

Does  tool  hel 
contro/mang^ 
nintinne? 

Ip  to 

5  a  fiederation  at 

type 

xs:  string 

annotation 

documentation 

Does  tool  help  to  control/mange 
a  federation  at  runtime? 
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Element  T oolList/T ool/ Application Area/F edEx/Perfor mance 


diagram 

Performance 

Is  tool  capable  oF  me 
Federation  execution 
performance? 

mitoring 

type 

xs:  string 

annotation 

documentation 

Is  tool  capable  of  monitoring  federation 
execution  performance? 

Element  T  oolList/T  ool/ Application  Area/F  edEx/RTI 


diagram 

"RTI 

Is  tool  a  RT 

I? 

type 

xs:  string 

annotation 

documentation 

Is  the  tool  a  RTI? 

Element  T oolList/T ool/Application Area/F edEx/F edExDocumentation 


diagram 

FedExDDCumentation 

Does  tool  help  to  document  a 
Federation  execution? 

type 

xs:  string 

annotation 

documentation 

Does  tool  help  to  document  a  federation  execution? 

Element  ToolList/Tool/ Application Area/FedEx/DataCollect 


diagram 

DataCollect 

Is  tool  a  data  colic 

iction  tool? 

type 

xs:  string 

annotation 

documentation  | 

1  Is  tool  a  data  collection  tool? 

Element  ToolList/Tool/ApplicationArea/FedEx/NetworkSptDevice 


diagram 

HetworkSptDeuice 

> 

Does  tool  support  network 
management  analysis^  etc.t^ 

type 

xs:  string 

annotation 

documentation 

Does  tool  support  network 
management,  analysis,  etc.? 
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Element  T oolList/T ool/Application Ar ea/F edEx/SecurityDevice 


diagram 

SecurityDeuice 

Is  tool  5  security  devic 

e? 

type 

xs:  string 

annotation 

documentation  | 

1  Is  tool  a  security  device? 

E.3.5  Leaf:  Viewers 

The  Viewer  leaf  is  used  to  describe  the  capabilities  of  the  tool  to  provide  a  2D  or  3D  view  of  exercise 
synthetic  environments  during  simulation  execution  (FEDEP  Steps  4  to  7). 

Element  ToolList/Tool/ApplicationAreaA^iewers 


diagram 

Viewers 

Is  tool  (tiintinn( 

5)  viewer? 

type 

extension  of  xs: string 

attributes 

Name 

Type 

Use 

Default 

Fixed 

ThreeDim 

xsiboolean 

optional 

false 

TwoDim 

xsiboolean 

optional 

false 

annotation 

documentation 

Is  the  tool  a  (runtime)  viewer? 

E.3.6  Leaf:  AAR 

The  AAR  leaf  contains  reviewer  comments  on  the  use  of  the  tool  for  After  Action  Review  (AAR) 
activities,  including  data  collection  during  federation  test  and  execution  (FEDEP  Steps  5  to  7).  In  the  case 
of  a  general-purpose  tool,  the  comments  would  refer  to  the  ability  of  the  tool  to  produce  software  or 
databases  to  be  used  during  AAR  activities. 


Element  T oolList/T ool/Application Area/AAR 


diagram 

"AAR 

Is  tool  an  ^ 
Review  too 

^Fter  Action 

:|? 

type 

xs:  string 

annotation 

documentation 

Is  tool  an  After  Action  Review  tool? 

E.3.7  Leaf:  CCISJF 

The  CCIS_IF  leaf  describes  the  use  of  the  tool  for  interfacing  simulations  to  CCIS  (during  FEDEP  Steps  4 
to  6),  or  in  the  case  of  a  general-purpose  tool,  the  ability  of  the  tool  to  produce  software  or  databases  to  be 
used  to  help  interface  simulations  to  CCIS. 
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Element  T  oolList/T  ool/ApplicationArea/CCIS_IF 


diagram 

"CCISJF 

Does  tool  support  coupling 
Commend  end  Control 
InFoimetion  Systems  (CCI 
into  fiederetions?  (e.g. 
concept  oF  dete  bese 
replicetion,  etc.) 

type 

xs:  string 

annotation 

documentation 

Does  tool  support  coupling  Command  and  Control 
Information  Systems  (CCIS)  into  federations? 

(e.g.  concept  of  data  base  replication,  etc.) 

E.3.8  Leaf:  W 

The  VV  leaf  contains  reviewer  comments  on  the  use  of  the  tool  for  verification  and/or  validation  activities 
(FEDEP  Steps  1  to  7).  In  the  case  of  a  general-purpose  tool,  the  comments  would  refer  to  the  ability  of  the 
tool  to  produce  software  or  databases  to  be  used  during  V&V  activities. 


Element  T  oolList/T  ool/ Application  Area/VV 


diagram 

"VV 

Does  tool  support  Velidetion 
end  Verificetion  oF  e 

Federetion  model  end 
implementetion? 

type 

xs:  string 

annotation 

documentation 

Does  tool  support  Validation  and  Verification 
of  a  federation  model  and  implementation? 

E.4  ELEMENT:  Furtherinformation 

The  Furtherinformation  element  captures  information  that  is  not  directly  related  to  the  application  of  the 
tool.  It  contains  eight  more  elements,  which  provide  contact  and  reference  information,  platform 
requirements,  tool  availability  and  support  information,  and  supported  input  and  output  standards. 
The  Customization  field  contains  reviewer  comments  on  the  ability  to  customise  the  tool,  which  often 
involves  the  dynamic  linking  of  user-provided  software  or  the  customisation  of  configuration  files. 
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Element  T oolList/T ool/F urtherinfor mation 


diagram 


Vendor  ^ 


Auailibilhy 


Licensing,  Relese  Cpnstreints 
(eps.  GOTS),  etc. 

Support"^ 


Furtherlnformation  [^1— 


Reference 

V 

1  ..CO 


Platform 


Customization 

'Inputs 

1  ..OO 

suppported  stenderds, 
Fomnets,  etc. 


Outputs 

I 

'  V 

1  ..OO 


children 


suppported  standards, 
Formats,  etc. 


Vendor  Availibility  Support  Reference  Platform  Customization  Inputs  Outputs 


Element  T oolList/T ool/Furtherlnfor mation/V endor 


diagram 

Vendor  [^l— 

Sponsor 

~Deueloper 

children 

Sponsor  Developer 

Element  ToolList/Tool/FurtherlnformationA^ endor/Sponsor 


diagram 

Sponsor 

type 

extension  of  xs:  string 

attributes 

Name 

Type 

Use 

Default 

Fixed 

NameOfSponsor 

xs:  string 

optional 

Contactinformation 

OfSponsor 

xs:  string 

optional 
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Element  ToolList/Tool/FurtherlnformationA^  endor/Developer 


diagram 

Developer 

type 

extension  of  xs:  string 

attributes 

Name 

Type 

Use 

Default 

Fixed 

NameOfDeveloper 

xs:  string 

optional 

ContactInformationOfDeveloper 

xs:  string 

optional 

Element  T  oolList/T  ool/EurtherInformation/Availibility 


diagram 

Auailibility 

Licensing,  Relase  Cpnstraints 

(eps.  GOTS),  etc. 

type 

xs:  string 

annotation 

documentation 

Licensing,  Release  Constraints  (e.g.  GOTS),  etc. 

Element  ToolList/Tool/EurtherInformation/Support 


diagram 


HelpDesk 

Support  l^l— (— ^JEl— 

Documentation 

Online  (within  the  too[), 
Hardcopy,  Web  Based  (via 
Internet) 


children 


HelpDesk  Documentation 


Element  ToolList/Tool/FurtherInformation/Support/HelpDesk 


diagram 

HelpDesk 

type 

xs:  string 

Element  T oolList/T ool/F urtherInformation/Support/Documentation 


diagram 

Documentation 

Online  (within  the  tooO. 
Hardcopy,  Web  Based  I 
Internet) 

(via 

type 

restriction  of  xs: string 

annotation 

documentation 

Online  (within  the  tool).  Hardcopy, 

Web  Based  (via  Internet) 
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Element  T oolList/T ool/F urtherinfor mation/Refer ence 


diagram 

Reference 

attributes 

Name 

Type 

Use 

Default 

Fixed 

Name 

xs:  string 

optional 

Program 

xs:  string 

optional 

Contactinformation 

xs:  string 

optional 

Element  T  oolList/T  ool/F  urtherinfor  mation/Platform 


diagram 

Platform 

attributes 

Name 

Type 

Use 

Default 

Fixed 

os 

xs:  string 

optional 

Memory 

xs:  string 

optional 

Compiler 

xs:  string 

optional 

OtherSWRequired 

xs:  string 

optional 

Hardware 

xs:  string 

optional 

Element  T  oolList/T  ool/F  urtherinfor  mation/Customization 


diagram 

Customization 

type 

xs:  string 

Element  T  oolList/T  ool/F  urtherinfor  mation/Inputs 


diagram 

Inputs 

suppported 
fiomriats,  etc 

standards, 

type 

extension  of  xs: string 

attributes 

Name 

Type 

Use 

Default 

Fixed 

InputDependencies 

xs:  string 

required 

none 

annotation 

documentation 

Supported  standards,  formats,  etc. 

Element  T  oolList/T  ool/F  urtherinfor  mation/Outputs 


diagram 

Outputs 

suppported  st< 
fiomnats,  etc. 

sndards, 

type 

xs:  string 

annotation 

documentation 

Supported  standards,  formats,  etc. 
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The  table  below  serves  as  a  quick  reader’s  guide  to  the  information  provided  by  the  tool  list  (as  it  is,  July 
2003). 

The  description  of  the  various  tools  originates  either  from  personal  experiences  or  user  interviews.  Only  in 
some  rare  cases  was  third-party  information  included.  In  such  cases,  publicly  available  sources  (such  as 
Internet  sites)  were  used;  however,  special  care  was  taken  to  ensure  that  no  purely  commercial  statements 
and/or  advertising  were  included  in  the  table. 

It  should  be  stressed  that  although  a  comment  is  by  its  very  nature  subjective,  the  statements  given  within 
the  table  reflect  no  qualifying  ranking  in  the  sense  of  “tool  X  is  excellent/good/poor”.  Instead,  the  table 
indicates  the  FEDEP  steps  where  the  tool  is  likely  to  be  useful. 


Name  of  Tool 

Supports 

FEDEP 

Steps 

Description/Comment 

BAMBOO 

4,5 

Enable  applications,  regardless  of  their  environmental  platform(s)  or 
programming  language(s),  to  be  dynamically  reconflgurable  (take  on 
new  functionality  at  runtime). 

Calytrix 

SIMplicity 

4,  5,6 

SIMplicity  is  an  integrated  development  environment  (IDE)  that 
enables  developers  and  scientists  to  rapidly  assemble  component- 
based  HLA  simulations  from  new  and  pre-existing  components  in  a 
visual  environment.  SIMplicity  assists  the  developer  throughout  the 
development  life  cycle,  from  design  to  development,  deployment  and 
execution.  SIMplicity  uses  a  template-driven  code  generation  process 
to  create  all  of  the  simulation  entities  for  the  targeted  platform 
specific  simulation  model  (PSM). 

CERTI 

4,  5,6 

Experimental  RTI  developed  by  the  French  ONERA  institute. 

DART 

3,4 

Regenerates  and  optimizes  existing  visual  terrain  databases  for  new 
platforms;  can  create  new  versions  based  on  how  new  sensors  would 
“see”  the  terrain. 

DOT 

4,  5,  6,  7 

AAR  DMSO  tool. 

DEVS 

4,  5,6 

Discrete  Event  System  Specification  (DEVS)  is  a  framework  for 
understanding  and  supporting  the  activities  of  modeling  and 
simulation,  based  on  generic  dynamic  systems  concepts. 

DIS  Network 
voice 

5,6 

Provides  a  simulated  radio  model  with  shared  or  individual  radio 
access  for  operators  located  on  dispersed  network  nodes. 

DIS  WAN 
gateway 

5,6 

Support  execution 

DOORS 

1,2,3 

Requirement  Management  Tool 

Equater 

4,5 

Scenario  Generation 

FedDirector 

4,5,6 

Part  of  HLA  Lab  Works,  provides  the  means  to  monitor  and  control 
the  federation  execution. 

FedProxy 

4,5 

Part  of  the  HLA  Lab  Works  suite,  can  debug  federate’s  HLA 
interface,  perform  tests  of  the  RTI  &  network,  and  even  provide  a 
stand-in  for  missing  federates.  Part  of  HLA  Lab  Works  Suite  Tests 
HLA  interface. 
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FEPW 

4,5 

HLA  support  DMSO  tools 

FLSIM/HELISIM 

4,5 

Reconfigurable  fixed  or  rotary  wing  high-fidelity  aero-model  which 
can  integrate  with  any  technology  which  HLA  enables  a  simulation. 

FMT 

5,6 

HLA  support  DMSO  tools 

FVT 

5,6 

HLA  support  DMSO  tools 

GERTICO 

4,5,6 

Modular  RTI  based  on  CORBA. 

GL  Studio 

3,4 

One  tool  in  the  category  of  rapid  application  development. 

HFC  SDK  1.3 

4,5 

The  HFC-SDK  1.0  included  the  HLA  Foundation  Class  (HFC) 
Framework,  the  OMLib  Library,  the  HFC  Automation  Tool  (HAT) 
on  Windows  only,  and  an  HFC  rework  of  the  HelloWorld  sample 
federate  included  with  the  DMSO  RTI1.3v6.  The  HFC  provides  an 
application  framework  for  HLA  federates  in  much  the  same  way  the 
Microsoft  Foundation  Class  (MFC)  library  provides  a  framework  for 
Windows  applications.  OMLib  offers  the  ability  to  dynamically  read 
in  and  manipulate  HLA  object  model  data  from  OMT-DIF  files.  The 
HAT  automates  the  process  of  mapping  HLA  object  model  content  to 
C++  source  code  (providing  traceability)  through  specialization  of 
HFC  components.  HFC  SDK  1.3  is  the  current  update  to  HFC-SDK 

1.0  and  enables  development  of  HLA  federates  to  collaborate  with 
the  DMSO  RTI  I.3v6. 

HLA  Control 

4,  5,6 

It  has  all  the  functionality  of  the  standard  HLA  FEPW,  plus  full  life- 
cycle  federation  management  capabilities.  It  makes  it  fast  and  easy  to 
plan  your  federation,  determine  if  performance  requirements  are 
satisfied  and  even  identify  and  correct  run  time  inaccuracies. 

HLA  Exercise 
explorer 

5,6 

A  fully  functional  HLA  Manager  Federate  designed  to  aid  in  the 
development  of  HLA  Federates  and  Federations.  The  Exercise 
Explorer  provides  the  developer  with  critical  information  about  the 
current  running  state  of  an  HLA  Federation  Execution  including  run 
time  information  on  each  Execution  Member. 

HLA  Integration 
Framework 

5,6 

The  framework  software  provides  ready-made  use  of  many  HLA 
functions  and  simpler  interfaces  to  the  RTI. 

HLA  Results 

4,  5,  6,  7 

Is  a  comprehensive  data  management  system  with  all  the  features 
needed  to  collect,  store  and  understand  federation  data. 

HP  Openview 
Network  Node 
Manager 

5,6 

Local  area  and  wide  area  network  management  tool. 

Ibis  Model  Editor 

3,4,  5,6 

Ibis  Model  Editor  is  a  CAFDE-compliant  software  package  designed 
to  create  HLA-compliant  models.  Model  Editor  is  still  in  a  beta,  not 
final,  stage.  As  such  it  may  not  be  as  refined  as  a  final  product  would 
be.  Trial  copies  may  be  downloaded  for  evaluation  purposes  only. 

Ibis  RTI  Adapter 

3,4,  5,6 

Ibis  RTI  Adapter  is  an  ActiveX  component  that  exposes  DoD’s  HLA 
(High  Level  Architecture)  RTI  (Run  Time  Infrastructure)  to 

COM/ ActiveX  applications. 
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Interdaptor 

4,  5,6 

Provides  a  customizable  out  of  the  box  solution  to  you  simulation 
interoperability  needs.  Provides  true  interoperability  between  HLA, 
DIS,  and  customized  interfaces  or  protocols;  achieves  cost-effective 
HLA  compliance;  and  allows  interoperability  between  legacy  and 
other  systems. 

Intersim 

5,6 

InterSIM  software  enables  simulations  and  instrumented  systems  to 
be  networked  together  in  the  same  synthetic  environment  according 
to  DIS  IEEE  1278.I-I995  or  HLA  standards.  HLA  RTI  specs  1.1 
with  DMSO  RTI  1.0. 

ITEMS 

4,  5,6 

ITEMS  provides  simulation  and  CGF  capabilities;  see  also  STRIVE. 

Liteflite 

3,4 

LiteFlite  TM  Re-Configurable  Simulation  Toolkit  Is  Low-Cost,  PC- 
Based  Solution  Providing  Photo-Realistic  Geo-Specific  Dynamic 
Environments. 

MAK  Data 

Logger 

4,  5,6 

The  MAK  Data  Logger  is  a  system  for  capturing  and  relaying 
simulation  data. 

MAK  Gateway 

5,6 

The  MAK  Gateway  translates  DIS  PDUs  into  RTI  service 
invocations,  and  vice  versa,  in  real-time. 

MAK  PVD 

4,5,6 

Provides  Multiple  Map  Views,  Controls  Stealth,  Calculates  Line-Of  - 
Sight,  Displays  Contours  and  Grid  Lines,  Language  Independent, 
Extensible  Through  Plug-In  Interface,  FOM- Agile  Through  VR- 
Link’s  FOM-Mapper  Architecture. 

MAK  Real-time 
RTI 

5,6 

No  RTI  executive  or  other  central  server  is  necessary  to  use  the  MAK 
RTI,  making  initialization  quick  and  easy.  It  can  be  configured  to  use 
point-to-point,  broadcast,  or  multicast  communications  for  maximum 
flexibility  across  different  network  architectures.  Optimized  for 
realtime  simulations. 

MAK  Stealth 

4,5,6 

Used  for  3D  visualization,  situation  awareness,  debugging  a 
simulation,  or  after-action  review. 

MAK  VR  Forces 

4,5,6 

CGF  Mak  tools.  Not  a  tool  to  support  process  but  a  possible  federate. 

ModlOS  2D  PVD 

4,  5,6 

The  Plan  View  Display  (PVD)  is  one  application  in  the  ModlOS  tool 
suite.  It  provides  a  2D  view  of  the  simulation  and  configurable  icons. 
Designed  for  DIS  and  included  HLA  gateway. 

ModlOS  3D 

Stealth  Viewer 

4,  5,6 

The  Stealth  Viewer  is  one  application  in  the  ModlOS  tool  suite.  It 
provides  a  3D  display  of  the  battlefield  from  various  points  of  view 
(cockpit,  independent,  etc.)  Supports  smoothing  of  entity  positions, 
special  effects  such  as  explosions,  and  atmospheric  effects.  Designed 
for  DIS  and  included  HLA  gateway. 

ModlOS  AAR 

5,  6,7 

The  After  Action  Review  (AAR)  is  one  application  in  the  ModlOS 
tool  suite.  It  provides  a  data  logging  and  replay  facility,  automatic 
generation  of  performance  reports,  and  remote  control  of  the  2D  PVD 
and  3D  Stealth  Viewer.  Designed  for  DIS  and  included  HLA 
gateway. 

ModlOS  Exercise 
Controller 

5,6 

The  Exercise  Controller  is  one  application  in  the  ModlOS  tool  suite. 

It  provides  configurable  control  of  simulation  applications,  including 
2D  and  3D  displays,  computer-generated  forces,  etc.  It  is  used  to 
start,  resume,  stop  and  freeze  simulations,  generate  reports,  create  and 
remove  entities,  etc.  Designed  for  DIS  and  included  HLA  gateway. 
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ModlOS 

logger/player 

4,  5,6 

The  Logger/Player  is  one  application  in  the  ModlOS  tool  suite.  It 
provides  a  data  logging  and  replay  facility.  Designed  for  DIS  and 
included  HLA  gateway. 

ModlSE 

4,  5,6 

Framework  that  facilitates  composition  of  and  interoperability  among 
interactive  simulation  applications.  It  includes  a  web-based  model 
repository,  a  GUI  and  a  run-time  Interoperability  engine.  ModlSE 
stands  for  Modular  Interoperable  Synthetic  Environment. 

ModSAF 

4,  5,6 

CGF,  Not  a  tool  to  support  process  but  a  possible  federate.  Retired 
software  that  is  being  replaced  by  OneSAF  Test  Bed  version  1.0. 

Multigen  2 

3,4 

Graphics  development 

Multigen  Creator 

3,4 

Creator  is  a  comprehensive  toolset  for  the  rapid  generation  of 
optimized  object  models,  high  fidelity  terrain  and  synthetic 
environments  for  use  in  realtime  3D  visual  simulation,  simulation 
based  training,  and  urban  simulation. 

Multigen  Creator  - 
Sedris  export 

3,4 

MultiGen  SEDRIS  Exporter  is  a  plug-in  for  Creator  that  provides 
interoperation  technology  for  the  defense  training  and  simulation 
community.  The  SEDRIS  Exporter  is  a  flexible,  user-guided  SEDRIS 
database  production  solution  that  supports  STRICOM  and  DMSO’s 
Synthetic  Interoperability  Strategy  in  an  easy-to-manage  procedural 
workflow.  The  SEDRIS  Exporter  translates  industry  standard  3D 
OpenFlight  files  into  the  SEDRIS  Transmittal  Format  (.stf),  making 
this  an  invaluable  tool  for  any  project  with  SEDRIS  data 
requirements. 

OMDT 

3,4,5 

HLA  support  DMSO  tools. 

OMDT  Pro 

3,4,5 

Editor  for  creation  and  modification  of  SOMs  and  FOMs. 

Omni 

4,5 

Part  of  the  HLA  Lab  Works  suite,  used  to  Integrate  simulations  OMni 
is  a  set  of  related  software  components  and  applications  that  together 
give  simulations  the  ability  to  establish  a  Federation  Object  Model 
(FOM)  independent  interface  to  the  HLA  Runtime  Infrastructure 
(RTI).  Part  of  the  HLA  Tool  Suite  Middleware  used  to  integrate 

FOMs. 

OneSAF  Testbed 

4,5,6 

CGF. 

pRTI 

5,6 

Pitch’s  portable  Runtime  Infrastructure  (pRTI)  is  a  platform 
independent  software  that  provides  HLA  services  used  by  federates  to 
co-ordinate  their  operations  and  data  exchange  during  an  HLA 
federation  execution.  pRTI  implements  all  services  documented  in 
the  HLA  Interface  Specification  vl.3. 

pRTI  for  IEEE 

1516 

5,6 

The  product  implements  the  entire  1516  standard.  First  commercial 
IEEE  1516  RTI. 

PSI-SA 

3,4,5 

User  friendly  API  to  RTI.  Stresses  the  modelling  aspect. 

RAL  Wrapper 

4,5 

RTI  Abstraction  Layer  for  C++  developed  simulation.  Facilitate 
design,  allow  automatic  generation  of  code  and  execution. 

RealDB 

3,4 

Realistic  up-to-date  models.  Canadian,  Russian,  and  U.N.  army 
equipment  visual  models,  3  levels  of  detail  plus  damage  states. 

S2Focus 

4,  5,6 

Provides  exercise  management  tools,  including  a  Mission  Planner, 
Recorder,  Manager,  Viewer,  and  Analyzer. 
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SAIDA 

4,5,6 

Security  extensions  to  the  RTI  prototype  (CERTI)  developed  at 
ONERA  (Office  National  d’Etudes  et  de  Recherches  Aerospatiales). 
These  extensions  are  aimed  at  guaranteeing  secure  interoperation  of 
simulations  belonging  to  various  mutually  suspicious  organizations. 

It  is  an  UK/F  cooperation. 

Sedris  tools 

3,4 

A  synthetic  environment  data  interchange  programme. 

Sequoia  Integrator 
for  HLA 

4,5 

The  Integrator  provides  the  means  to  rapidly  integrate  new  or  existing 
simulation  systems  into  HLA  environments.  SEQUOIA  Integrator  for 
HLA  vl.O  is  currently  available  on  Windows  NT©  for  use  with 
RTH.3NG-V3. 

SGT 

3,4 

Scenario  generation  HLA  lab  works. 

Simplex  3 

4,  5,6 

The  main  design  concept  behind  the  HLA-interface  of  Simplex  3  is  to 
hide  all  HLA-functionality  from  the  model  developer.  It  should  be 
noted,  that  this  approach  leaves  the  entire  model  description  of 
Simplex  3  models  unchanged,  no  matter  if  they  act  as  stand-alone 
models  or  federates  in  the  sense  of  HLA.  With  that  kind  of  an  HLA 
interface  the  entire  interoperability  issue  is  part  of  the  simulation 
system  itself,  and  thus  not  part  of  the  simulation  model.  One  the  one 
hand  this  facilitates  the  re-use  of  existing  models,  and  on  the  other 
hand  the  developer  of  new  models  does  not  need  to  have  additional 
knowledge  for  building  HLA-compliant  models. 

Simulation 

Support 

Environment 

DUCTOR 

3,  4,  5,  6 

DUCTOR  is  an  architecture  which  allow  to  develop  operational 
simulations  running  stand-alone  or  as  an  HLA  federate.  It  is  OO 
(UML  based)  and  promotes  re-use  of  scenarios,  specific  behaviours 
and  platforms. 

Simulation 

Support 

Environment 

ESCADRE 

3,  4,  5,  6 

Encapsulate  and  hide  low  level  HLA  interface  functionality, 
providing  high  level  services  for  HLA  interoperability.  Provide  an 

OO  methodology  and  a  tool  set  to  design,  implement  and  run  stand¬ 
alone  simulations  and  HLA  federates. 

Skopeo  Animation 
System 

4 

In  order  to  run  in  a  distributed  environment,  Skopeo  was  extended  for 
HLA.  This  extension  uses  the  Beta  release  of  the  Java  RTI  API  from 
DMSO.  Skopeo  once  was  developed  as  Proof  Animation  (R) 
compatible  2D  animation  tool  for  post-run  trace-file  based  animation. 

It  is  written  in  Java  and  runs  stand-alone  or  as  applet  in  any  java- 
capable  web  browser.  In  a  second  step,  Skopeo  was  enhanced  for  3D 
animation  using  VRML2.0  if  an  appropriate  browser  plug-in  can  be 
found.  Additionally  CORBA  mechanisms  are  used  for 
communication  between  the  Skopeo  Applet  and  the  Skopeo  server. 

SEX  Simulation 
Environment 

4,5 

HLA  interface  provided  SEX  is  a  very  fast  discrete  event  simulation 
tool  for  the  Windows  95/98/NT  operating  systems.  It  is  a  simulation 
language  oriented  tool.  The  SEX  user  is  provided  with  an  easy-to-use 
interface  to  the  RTI  and  the  possibility  of  “doing”  distributed 
simulation  based  on  HLA  without  having  to  deal  with  the  lowest 
API-level  of  HLA. 

SmartFED 

4,5,6 

HLA  support 

SMOG 

5,6 

SMOC  is  a  standard  interface  to  HLA  for  developers  of  models  and 
simulations.  Serves  as  a  DIS/HLA  gateway  to  avoid  expensive 
modifications  to  DIS-compliant  systems. 
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SPEEDES 

4,  5,6 

Simulation  Engine  used  for  JSIMS. 

STAGE 

4,  5,6 

Complex  tactical  scenario  generator  product  which  can  integrate  with 
any  technology  which  HLA  enables  a  simulation;  can  participate  in 
HLA  federations,  when  jointly  used  with  the  ModlOS  Network 
Complex  tactical  scenario  generator  product  which  can  integrate  with 
any  technology  which  HLA  enables  a  simulation;  can  participate  in 
HLA  federations,  when  jointly  used  with  the  ModlOS  Network 
Interface  from  Motorola. 

STRIVE 

4,  5,6 

Synthetic  Tactical  Real-time  Interactive  Virtual  Environment 
(STRIVE)  is  a  COTS  simulation  development  environment.  Reduces 
development  through  existing  libraries  of  models.  Many  aspects  of 
the  software  can  be  modified  or  replaced  with  user-defined  software. 

It  also  has  a  CGF  capability.  Although  quite  new.  Strive  is  expected 
to  be  a  major  COTS  software  product  of  CAE.  It  can  run  as  a  federate 
and  provides  a  framework  for  creating  the  same. 

Telestra  HLA 

4,  5,6 

Supports  execution.  Remote  HLA  Management,  Radio  Simulation 
and  Communications. 

Terra  Vista/Terra 
Vista  Pro  Builder 

3,4 

Used  to  create  visual  terrain  databases  in  OpenFlight  or  TerraPage 
formats.  ProBuilder  version  intended  for  “power  users”.  Both 
versions  are  extensible. 

TerraTools 

3,4 

Terrain  DB  Construction  Tool. 

UOB  DAT 

2,  3,4 

MSIAC  Web  Page;  Support  Exercises  Composition. 

VAPS 

4 

Rapid  prototyping  of  complex  human  computer  interfaces;  generates 
C-Code  which  can  be  HLA  enabled  using  any  HLA  integrator 
product. 

VEGA 

3,4,5 

Vega  Prime  is  a  software  environment  for  the  creation  and 
deployment  of  realtime  visual  simulation,  virtual  reality,  sensor  and 
general  visualization  applications.  Vega  Prime  combines  advanced 
simulation  functionality  with  easy-to-use  tools  to  create  an 
infrastructure  to  build,  edit  and  run  sophisticated  applications. 

Visual  OMT 

3,4,5 

Visual  OMTT  is  a  project-based  multiple-document  (MDI) 
application  supporting  Simulation  Object  Models,  Federation  Object 
Models  and  Data  Dictionary  documents.  Object-model  elements  can 
be  copied  within  and  between  documents  by  drag  and  drop. 

VR  Link 

4 

With  MAK’s  VR-Link  networking  toolkit  you  can  easily  and  quickly 
network  simulators  and  virtual  reality  applications  together,  using  the 
HLA. 

yaRTI 

5,6 

yaRTI  is  an  HLA  RTI  implemented  in  Ada95,  using  the  Distributed 
Systems  Annex  features. 
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